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This  report  describes  a digital  computer  model,  NETMAN,  and  its  imple- 
mentation for  simulating  the  information  processing  in  a semi- automated 
system  with  Army  personnel  during  field  exercises,  using  a computer  based 
message  handling  system. 

The  NETMAN  model  was  designed  to  allow  simulation  of  message  processing 
in  a system  composed  of  up  to  three  networks.  Each  network  may  be  composed 
of  up  to  nine  referees,  up  to  nine  radio  operators,  and  one  controller. 
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CLAMiriCATlOW  or  THIS  PM€(Whmt  Dmtm  Kntt^ 

20.  'One  computer  is  assumed  to  accommodate  the  three  networks.  As  such, 
the  model  allows  simulation  and  test  o£  the  effects  on  system  effectiveness 
of  varying  such  aspects  as:  number  of  referees,  number  of  networks,  task 
procedures,  message  arrival  rate,  message  length,  and  operator  skill. 

The  results  of  the  simulation  are  Interpretable  in  terms  of  a number  of 
formal  effectiveness  measures  (accuracy,  thoroughness,  responsiveiii’:is,  complete- 
ness'' and  an  overall  effectiveness  index.  Additionally,  the  results  are 
interpretable  in  terms  of  such  model  results  as  work  time,  stress  imposed, 
message  processing  time,  errors,  number  of  messages  processed,  and  fatigue. 

The  Appendices  contain  flowcharts,  data  item  information,  individual 
definitions  for  each  model  subroutine,  and  input-output  formats.  This 
information  is  organii^ed  to  serve  as  a user's  manual  for  those  who  wish  to 
apply  the  model  for  adulation. 
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PREFACE 


The  computer  model > NETMAM,  described  in  the  report  that  follows  was 
developed  by  Applied  Psychological  Services,  Inc.  under  contract  DAHC  19- 
76-C-0013.  The  specific  requirements  for  this  effort  were  established  by 
the  Army  Research  Institute  for  the  Behavioral  and  Social  Sciences  (ARl) 
within  a continuing  Army  training  project  and  in  response  to  the  special 
needs  of  the  Army  Combat  Arms  Training  Board  and  the  Training  Device 
Requirements  Office,  now  the  Army  Training  Support  Center,  Fort  Benning, 
GA. 


Field  training  exercises  (FTX)  serve  an  Important  role  irf  the 
training  of  units  for  the  rapid  transition  from  peacetlm'e  readiness  to 
wartime  effectiveness  on  the  modern,  highly  lethal,  dynamic  battlefield. 
The  current  manual  system  * for  conducting  an  FTX  Imposes  Costly  demands 
on  resources  during  the  period  necessary  to  form  and  train  the  exercise 
staff  and  to  plan,  conduct,  and  report  on  the  exercise.  In  addition,  the 
methods  and  techniques  for  maneuver  control,  casualty/ damage  assessment, 
and  simulation  of  combat  events  are  unwieldy  and  time  consuming,  degrad- 
ing the  training  effectiveness.  In  order  to  Improve  the  cost-training 
effectiveness  of  conducting  an  FTX,  the  Army  has  initiated  a program  to 
develop  a computer  assisted  exercise  control  support  system.  This 
report  describes  a portion  of  ARI's  efforts  in  support  of  this  develop- 
ment— the  development  of  a computer  model,  NETMAN,  as  a tool  for  analysis, 
design,  and  assessment  of  candidate  systems.  This  development  responds 
to  needs  which  are  established  in  HRN  76-132*  and  HRN  77-27*. 

Based  on  a general  purpose  model  of  information  processing  systems, < 
this  model  simulates  operations  (l.e.,  staff  duties/functions  and  machine 
functions)  as  a joint  function  of  the  interactions  between  the  exercise 
data  flow,  human  information  processing,  and  other  sources  of  variance 
(e.g.,  personnel  characteristics)  to  produce  predictions  of  overall 
system  performance.  On-line  Inputs  to  the  program  permit  simulation  of 
candidate  configurations  that  reflect  changes  in  personnel/machine 
functions,  the  equipment/device  complement  (particularly  at  the  man- 
machine  interface) , and  level  of  personnel  training  for  comparison  of 
alternatives  (l.e.,  the  ability  to  ask  "what  if"  questions  on-line. 


' JM  105-5,  Maneuver  Control,  31  December  1973. 

2 • 
HRN  76-132,  "Improved  control  systems  for  field  training  exercises," 

submitted  by  U.S.  Army  Combat  Arms  Training  Board;  MAJ  Robert  Kelvit, 
user  point  of  contact. 

^ HRN  77-275,  "A  tool  for  the  assessment  of  alternative  command  group 
training  systems,"  submitted  by  U.S.  Army  Training  Device  Requirements 
Office;  MAJ  David  Blodgett,  user  point  of  contact. 

* Baker,  J.  D.  Quantitative  modeling  of  human  performance  in  information 
systems.  U.S.  Army  Research  Institute  for  the  Behavioral  and  Social 
Sciences,  Technical  Research  Note  232,  June  1972. 
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In  addition  to  an  overall  measure  of  performance,  the  system  provides 
four  component  measures  on-line  with  detailed  printouts  available  off- 
line as  system  status  snapshots. 

' This  model  capitalizes  on  earlier  work  by  ARrI  in  support  of  the 
U. S.  Army's  first  developmental' automated  tactical  operations  system, 

TOS.  The  TOS  modeling  effort’ waS  tharacterlzed  by  a twofold  interactive 
approach  linking  laboratory  research  and  field  studies  as  well  as  human 
performance' and  system  perfotniance.  As  the  system  design  evolved, 
the  need  to  verify  and  evaluate  the'iban/machlne  Interfaces  and  relate 
their'  performance’  to  the  bWrall  system  performance  was  recognized. 

The  general  purpose  model  was  found  to  be  a useful  simulation  and 
development  tool.  This  evolution  led  to  three  computer  versions  of  the 
model:  batoh  processing;*'  on-line,*  and  interactive.’  The  interactive 
version  can  capture  task  performance  data  from  operators  serving  in  a 
simulated  system  context  with  art  on-line  experimenter  to  record  the 
relevant  ancillary  activlt'ies/events.  'The  resulting  data  store,  when 
reduced  and  treated  statistically,  provides  input  parameters  for  the 
simulation;  Additional  features  introduced  during  the  course  of  develop- 
ment include  a generalized  error  schema,  interface  options  with  a model 
of  communication  flow  in  multichannel  systems  (CASE),  and  a model  of  TOS 
computer  System  with  ancillary  equipment  (TOS/SAM).* 

ART  participation  in  this  development  of  exercise  control  systems 
was  initiated  In  response  to  a' request  for  technical  assistance  from 
the  Combined  Arms  Training  Board  (CATB) . The  Training  and  Doctrine 
Command  (TRADOC)  had  tasked  CATB  to  evaluate  the  Tactical  Warfare  Analysis 
and  Evaluation  System  (TUAES),  developed  by  the  US  Marine  Corps,  for 
potential  use  by  the  Army.  TWAES  is  a computer-based  aid  to  the  exer- 
cise control  staff  conceived  as' an  information  processing  system  with 
design  predicated  on  automation  of  those  staff  functions  which  were 
time  consuming  and  error  prone. 


’ Siegel,  A.  I.,  Wolf,  J.  J. , & Leahy,  W.  R.  A digital  simulation  model 
of  message  handling  in  the  tactical  operations  system:  1.  The  model, 
its  sensitivity  and  user's  manual.  U.S.  Army  Research  Institute  for 
the  Behavioral  and  Social  Sciences,  Technical  Report  TR-77-A23, 

October  1977. 

* Leahy,  W.  R. , Lautman,  M.  R. , Wolf,  J.  J.  Bearde,  J.  L. , & Siegel,  A.  I. 
A digital  simulation  model  of  message  handling  in  the  tactical  opera- 
tions system:  III.  Further  extension  of  the  model  for  Increased 
Interaction.  U.S.  Army  Research  Institute  for  the  Behavioral  and 
Social  Sciertces,  Technical  Report  TR-77-A25,  October  1977. 

’ Siegel  A.  I.,  Wolf,  J.  J. , Leahy,  W.  R. , & Bearde,  J.  L.  A digital 
simulation  model  of  message  handling  in  the  tactical  operations  system: 
II.  Extensions  of' the  model  for  interactivity  with  subjects  and 
experlmehters.  U.S.  Army  Research  Institute  for  the  Behavioral  and 
Social  Sciences,  Technical  Report  TR-77-A24,  October  1977. 

* Leahy,  U.  R. , Siegel,  A.  I. , & Wolf,  J.  J.  A digital  simulation  model 
of  message  handling  In  the  tactical  operations  system:  IV.  Model 
integration  with  CASE  and  SAMTOS.  In  press. 
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The  results  of  the  TWAES  evaluation  supported  the  introduction  of 
automation  as  a viable  approach  to  improvement  of  field  exercises  but 
determined  that  the  Army  needs  would  best  be  satisfied  by  development 
of  a "fully  integrated  system  for  control  of  field  training  exercises," 
to  include  current  and  projected  advanced  technology  in  engagement 
simulation,  command  and  control,  and  training.’  These  findings  were 
derived  from  the  use  of  TWAES  during  an  Army  battalion  level  Operational 
Readiness  Training  Test  (ORTT)  at  Ft.  Leid.s,  Washington,  September  1974, 
employing  units  of  the  9th  ID.  The  data  collected  Included  communication 
records  of  the  exercise  staff  during  the  ORTT.  This  data,  when  reduced 
and  treated  statistically,  will  provide  input  parameters  to  this  simula- 
tion program  which,  in  turn,  will  provide  the  actual  system  performance — 
permitting  comparison  with  estimates  of  a simulated  system's  performance. 
In  this  manner,  the  computer  simulation  may  be  calibrated  with  actual 
field  operations.  Future  plans  Include  the  validation  of  the  model  and 
use  of  the  simulation  to  explore  alternative  system  configurations, 
equipment,  procedures  and  allocation  of  function/ tasks  to  achieve 
a design  that  satisfies  the  Army  needs  for  development  of  a "fully 
Integrated,"  cost-training  effective  exercise  control  system. 
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U.  S.  Army  Combat  Arms  Training  Board,  Evaluation  Report: 
Warfare  Analysis  and  Evaluation  System,  December  1974. 


Tactical 


1 

I 


ACKNOWLEDGMENT 


Our  sincere  thanks  are  extended  to  others  who  made  contributions  ' 

: to  the  developments  reported  here.  Mr.  Frederick  Michler  participated 

in  a portion  of  the  programming  of  the  model. 

Mr.  Robert  Hartman  of  the  Techniques  Division,  Management  In- 
formation Systems  Directorate,  Aberdeen  Proving  Ground,  and  Mr.  Gerald 
Adams  of  the  Scientific  and  Engineering  Applications  Division.  Aberdeen 
Proving  Ground,  provided  considerable  assistance  in  the  U1108  system  as- 
pects during  the  program  testing  phase. 

We  are  also  indebted  to  Dr.  Irving  Alderman  and  Mr.  James  Baker 
of  the  U.  S.  Army  Research  Institute  for  the  Behavioral  and  Social  Sciences 
for  their  valuable  advice  and  assistance  in  determining  the  scope,  basic 
f approach,  and  design  objectives  to  which  the  model  was  developed. 

' Arthur  I.  Siegel 

[ Wm.  Rick  Leahy 

J J.  Jay  Wolf 

j ; applied  psychological  SERVICES,  INC. 

September  1976  | 

I 

] 

: i 


tv 


TABLE  OF  CONTENTS 


Page 


I.  INTRODUCTION  AND  BACKGROUND  1 

General  Overview 1 

Goals  of  the  Model 2 

Prior  Message  Processing  Models 3 

Scope  of  This  Report 4 

II.  THE  SYSTEM  SIMULATED  AND  THE  NETMAN  MODEL 5 

Message  Processing  Flow 5 

Procedure  for  Simulation 9 

Overview  of  the  Simulation  Model 10 

On-Line  Experimenter  Control 10 

Message  Generation  and  Representation 10 

Message  Processing 16 

Stress 16 

Aspiration 18 

Fatigue 21 

Operator  Processing  Time 24 

Task  Element  Success  Probability 2 7 

Information  Loss 31 

Effectiveness  Measures 31 

Computer  and  Controller  Delay 33 

Results  Recording 34 

III.  SENSITIVITY 39 

Results 42 

Speed 42 

Precision 45 

Message  Length  47 

Message  Frequency  53 

IV.  SUMMARY  AND  DISCUSSION  57 

REFERENCES  59 

APPENDIX  - USER'S  MANUAL  FOR  THE  NETMAN  MODEL 61 

MODEL  FLOW 85 

GLOSSARY  OF  VARIABLES 97 


V 


LIST  OF  FIGURES 

Figure 

2-1  Schematic  of  message  processing  flow 6 

2-2  Macro  flowchart  of  NETMAN  model 11 

2-3  NETMAN  stress  function 17 

2-4  Pace  adjustment  factor  as  a function  of  aspiration  and 

performance 20 

2-5  Mean  values  of  critical  fusion  frequency,  of  a tapping  and  of 

a grid  tapping  test  in  relation  to  hours  after  starting  work  . . 22 

2-6  Work  fatigue  function 23 

2-7  Time  adjustment  factor  due  to  stress 25 

2-8  Effect  of  operator  precision  parameter  on  task  element 

success  probability 2 9 

2-9  Success  probability  criteria  as  a function  of  stress 30 

2-10  Sample  detail  results 35 

2-11  Sample  end  of  hour  report 36 

2- 12  Sample  run  summary  report 37 

3-  1 Input  data  used  for  NETMAN  sensitivity  tests 40 

3-2  Message  processing  time  as  a function  of  operator  speed 43 

3-3  Message  handling  time  as  a function  of  operator  speed  44 

3-4  System  overall  effectiveness  as  a function  of  operator  speed.  . 46 

3-5  The  effect  of  operator  speed  on  thoroughness 47 

3-6  The  effect  of  operator  speed  on  responsiveness 48 

3-  7 Effect  of  operator  precision  on  message  processing  time  ....  50 


vl 


fe&ktoMlil 


Fig 


ure 


3-  8 
3-  9 


LIST  OF  FIGURES  (cont.  ) 

Page 

Message  haiidling  time  as  a function  of  operator  precision  ...  51 

System  overall  effectiveness  as  a function  of  operator  pre- 
cision  52 


3-10  Effect  of  operator  precision  on  completeness 54 


LIST  OF  TABLES 


Table 


Page 


Principal  Model  Subscripts 

I 

List  of  NETMAN  Subroutines .13 

Summary  of  Sensitivity  Test  Runs  Completed  . . 39 


vill 


1.  INTRODUCTION  AND  BACKGROUND 


General  Overview 

This  report  presents  a description  of  a digital  -'omputer  model 
and  its  implementation  for  simulating  the  information  processing  actions 
of  Army  personnel  during  field  exercises  using  a computer  based  message 
handling  system.  These  personnel  include  up  to  2 7 referees,  27  radio 
operators,  suid  3 controllers  interacting  in  a fixed  network  of  communica- 
tion lines  while  sharing  time  on  a Central  Computing  Center  (CCC).  Mes- 
sages introduced  into  the  system  are  input  by  referee/ radio  operator  per- 
sonnel, processed  by  the  CCC,  and  then  delivered  to  controllers  for  eval- 
uation. The  field  exercise  is  simulated  through  random  message  genera- 
tion based  on  pertinent  values  such  as  message  length,  type,  and  arrival 
time.  Each  generated  message  is  then  processed  through  a referee-radio 
operator-CCC-controller  network,  and  processing  time  is  determined 
along  with  a number  of  other  descriptive  indices. 

The  model  is  called  NETMAN.  During  NETMAN's  processing  of 
message  information,  the  model  places  particular  emphasis  on  certain 
human  performance  features  considered  to  be  important  in  a field  oper- 
ational system  of  this  sort.  These  include  operator  stress,  speed,  pre- 
cision, and  level  of  aspiration.  In  simulating  each  operator  (and  the 
CCC)  in  the  handling  of  each  message,  the  model  requires  as  input  an 
estimation  of  time  related  data  for  various  operator  tasks  to  be  accom- 
plished. These  tasks  include  functions  such  as  message  scanning,  data 
entry,  and  table  lookup.  The  work  of  each  operator  is  analyzed  prior  to 
simulation  into  these  tasks  and  the  probable  sequence  of  their  occurrence 
is  determined.  Data  are  prepared  which  provide  a pertinent  quantitative 
description  of  the  tasks,  and  these  data  are  entered  into  the  computer  in 
the  form  of  procedures  called  task  analyses. 

NETMAN  is  programmed  in  FORTRAN  IV  for  the  Univac  1108 
system.  It  is  organized  to  allow  the  user  to  conduct  various  simulation 
experiments  relative  to  the  field  exercises.  Each  computer  run  of  the 
model  represents  a simulation  of  a field  session  up  to  12  hours  in  dura- 
tion conducted  under  conditions  as  specified  bj  input  parameters.  Ex- 
amples of  exercise  input  parameters  include  the  frequency  of  messages 
entered  to  the  system,  the  number  of  operators,  and  the  speed  and  as- 
piration levels  of  these  operators. 
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The  overall  man-machine  performance  measure,  effectiveness,  is 
calculated  for  the  simulated  exercise  and  summarized  over  the  total  exer- 
cise. It  is  composed  of  four  independent  factors --thoroughness,  complete- 
ness, accuracy,  and  responsiveness. 

Goals  of  the  Model 

Output  from  the  model  is  presented  in  the  form  of  computer  tabu- 
lations. These  tabulations  provide  data  which  promote  insight  in  evaluat- 
ing alternatives  both  in  terms  of  absolute  and  relative  value.  The  printed 
output  is  designed  and  organized  so  as  to  provide  results  that  answer  ques- 
tions of  practical  importance,  such  as  the  following: 

1.  What  is  the  average  processing  time  for  a message 
through  the  network  as  a function  of  the  frequency 
of  input  messages,  operator  capabilities,  and  net- 
work configuration? 

2.  How  do  changes  of  input  parameters  affect  pre- 
dicted total  man-machine  effectiveness  values? 

3.  What  is  the  loading  situation  relative  to  idle  vs. 
busy  time  for  referees,  radio  operators,  the  CCC, 
and  the  controller? 

4.  How  great  a stress  is  placed  on  the  average  opera- 
tor of  each  type  and  what  is  the  fatigue  profile  over 
the  mission  for  each  type  of  personnel? 

5.  Would  changes  in  the  task  analysis  of  one  or  more 
operators  materially  affect  average  processing 
time  and  system  effectiveness? 

6.  What  are  some  effects  of  operator  failures  under 
various  conditions? 

7.  How  would  increased  personnel  training  or  im- 
proved personnel  selection  affect  system  perform- 
ance? 

The  program  presents  detailed  message  processing  listings,  if 
desired,  as  well  as  hourly  summary  and  run  summary  outputs.  The  de- 
tailed message  processing  output  shows  the  fine  grain  of  the  results  of 
the  simulation  of  each  task  in  *he  processing  of  messages. 
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The  hourly  summary  presents  a consolidation  of  the  results  of  a 
simulated  hour's  work  across  all  iterations  and  includes  items  such  as; 
number  of  messages  completed,  time  spent  working,  end  of  hour  stress 
level,  performance  and  aspiration,  time  spent  performing  various  proc- 
esses, and  average  time  per  message. 

The  simulation  run  summary,  produced  after  N iterations  of  the 
exercise,  includes  manpower  utilization,  message  processing  times,  ef- 
fectiveness indicators,  and  workload  summary  information. 


Prior  Message  Processing  Models 

The  NETMAN  model  represents  a new  model  and  computer  program. 
Yet,  many  of  the  approaches  and  techniques  are  taken  from,  or  are  exten- 
sions of,  a prior  (operational)  model,  developed  by  Applied  Psychological 
Services  in  collaboration  with  the  U.  S Army  Research  Institute  for  the  Be- 
havioral and  Social  Sciences,  for  simulating  the  U.  S.  Army's  Tactical 
Operations  System  (TOS).  The  earlier  model,  called  MANMOD,  simu- 
lates the  behavior  and  performance  of  up  to  six  men  who  function  as  ac- 
tion officers  and  input-output  device  operators  in  the  TOS  system.  These 
men  perform  tasks  similar  to  those  simulated  in  NETMAN  and  which  were 
also  organized  for  computer  processing  into  task  analysis  tables.  The 
mechanism  for  task-by-task  performance  evaluation  in  MANMOD  is  basic- 
ally the  same  as  is  used  in  NETMAN. 

MANMOD  was  originally  designed  for  batch  run  processing  in 
FORTRAN  rv  on  the  CDC  3300  computer.  In  this  form,  original  sensi- 
tivity runs  were  followed  by  validation  runs.  In  the  validation,  a high 
degree  of  correspondence  was  found  between  the  model's  output  and  a 
set  of  error  data  collected  from  an  independent  source. 

In  a follow-on  effort,  the  MANMOD  model  was  modified  to  oper- 
ate in  an  interactive  time-sharing  mode.  This  feature  allows  the  experi- 
menter (mission  analyst)  to  interact  in  a "conversational"  mode  with  the 
model  and  to  enter  data  "on  line.  " This  interaction  is  performed  through 
a terminal  and  greatly  increases  the  ease  with  which  simulations  can  be 
performed.  NETMAN  possesses  the  same  interactive  capabilities. 

A variant  of  the  MANMOD  was  also  developed  which  allowed  col- 
lection of  data  during  an  experiment  in  which  one  or  more  actual  oper- 
ators performed  a part  of  the  process  and  the  computer  simulated  the 
remainder  of  the  TOS  activity. 


More  recently,  MANMOD  was  adapted  for  the  Univac  1108  com- 
puter and  several  new  capabilities  were  added  which  increase  the  real- 
ism of  the  simulation.  It  was  modified  to  exchange  data  with  two  other 
independent  computer  models  in  such  a way  as  to  maximize  the  strong 
points  of  each  of  the  models. 

The  above  efforts  are  the  subjects  of  the  following  technical  re- 
ports: Siegel,  Wolf,  and  Leahy  (1973);  Siegel,  Wolf,  Leahy,  Bearde, 
and  Baker  (1973);  Leahy,  Lautman,  Bearde,  and  Siegel  (1974);  and 
Leahy,  Siegel,  and  Wolf  (1975). 

Other  areas  of  similarity  between  MANMOD  and  NETMAN  are: 

1.  the  message  generation  technique  is  similar. 

2.  the  operator  performance  and  aspiration  determina- 
tion technique  is  the  same. 

3.  some  of  the  parameters  and  two  of  the  four  effective- 
ness factors  are  the  same. 

4.  the  basic  nature  of  both  models  is  stochastic.  As  a 
result,  a number  of  repetitions  is  required  to  pro- 
duce a stable  result. 

5.  both  models  provide  lists  of  inputs,  optional  detailed 
output,  hourly  summaries,  and  run  summaries. 

Scope  of  This  Report 

The  primary  features  of  the  NETMAN  model  are  presented  in  nar- 
rative and  summary  flow  logic  form  in  the  next  chapter.  This  includes  a 
graphic  presentation  and  description  of  the  field  communications  network 
simulated  and  the  procedures  implemented  in  the  model. 

Chapter  111  shows  the  results  of  the  computer  runs  made  to  deter- 
mine the  acceptability  of  the  sensitivity  of  model  outputs  based  on  input 
variation.  Both  magnitude  and  direction  of  output  are  analyzed  for  rea- 
sonableness in  selected  categories  of  input  changes  for  operator  skill  lev- 
els and  message  sizes. 

The  last  chapter  discusses  the  developed  model  and  its  use. 

The  Appendices  contain  flowcharts,  data  item  information,  individu 
al  definitions  for  each  model  subroutine,  and  input-output  formats.  This 
information  is  organized  so  as  to  serve  the  function  of  a user's  manual  for 
those  who  wish  to  apply  the  model  for  simulation. 
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II.  THE  SYSTEM  SIMULATED  AND  THE  NETMAN  MODEL 


Message  Processin  g Flow 

The  field  exercise  situation  simulated  may  be  viewed  as  a message 
processing  network  configured  as  shown  in  Figure  2-1.  This  figure  sym- 
bolically displays  2 7 simulated  referees  (R2  through  R27)  receiving  simu- 
lated symbolic  input  messages  from  independent  sources  as  well  as  from 
one  of  three  simulated  controllers  (CON  1,  CON  2,  or  CON  3).  Messages 
are  indicated  by  the  symbol 

Each  simulated  referee  in  the  left  to  right  message  processing 
flow  performs  the  appropriate  procedure  on  the  simulated  message(s). 

This  is  shown  symbolically  by  a circle  in  which  TAR  (Task  Analysis) 
Referee)  appears.  A message  then  passes  to  the  corresponding  radio 
operator  (one  of  ROx  through  RO27)  for  processing  in  accordance  with 
some  specified  task  analysis  procedure,  circle  TAO. 

Up  to  27  simulated  messages,  each  processed  by  a different  radio 
operator,  could  then  be  ready  for  entry  into  the  CCC.  Entry  into  the  sim- 
ulated CCC  for  any  given  message  is  made  over  one  of  four  data  communi- 
cation lines  for  each  of  the  three  networks  shown.  Accordingly,  in  a given 
network,  there  may  be  up  to  nine  simulated  messages  competing  for  the 
four  available  CCC  input  lines. 

Telecommunication  lines  are  designated  in  Figure  2-1,  and  the  re- 
sultant queues  awaiting  CCC  actions  are  designated  by(^"-(^. 

On  a first-in,  first-out  basis,  the  CCC  processes  messages  from 
all  of  the  three  networds  in  accordance  with  its  task  analysis  procedure- - 
depicted  by  circle  TAC  (Task  Analysis,  Computer).  These  messages  then 
enter  another  queue  awaiting  action  by  one  of  three  controllers.  Each 
simulated  controller  then  assesses  and  operates  on  the  oldest  message 
from  his  network  in  the  queue  and  performs  in  accordance  with  the  task 
analysis  for  controllers  as  symbolized  by  circle  TAN. 

The  loop  is  closed  by  the  simulated  generation  of  new  messages 
by  the  controller  for  input  to  one  of  the  referees  in  his  nine-way  network 
as  a function  of  a parameter  input  to  the  model.  Besides  the  link  from 
the  controller  to  his  referees,  the  referees  are  also  interconnected  and 
may  generate  new  messages  as  a result  of  their  interactions  with  one 
another. 
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FIGURE  2-1.  SCHEMATIC  OF  MESSAGE  PROCESSING  FLOW 


The  descriptions  of  the  task  element -by-task  element  process 
comprising  the  TAR,  TAO.  TAC.  and  TAN  are  contained  in  the  Appendix. 


The  simulation  continues  until  the  number  of  messages  processed 
by  the  controllers,  LDONE,  exceeds  the  input  desired  value,  ICHAIN. 

The  basic  range  of  capabilities  of  the  model  is  presented  in  the 
list  of  principal  model  subscripts  shown  in  Table  2-1.  Table  2-1  indicates 
that; 

• each  message  introduced  into  the  system  is  given  a 
sequence  number,  CMSG,  which  is  retained  as  the 
message  is  processed  and  transfered  between  oper- 
ators 

• up  toK=  8 task  analyses  (procedure  list  data)  may  be 
developed  and  stored  as  input  for  reference.  Any 
task  analysis  may  be  assigned  to  any  of  the  JMAX  = 

4 levels  (R,  RO,  CON,  CCC) 

• each  task  analysis  may  consist  of  up  to  NTE=  10 
task  elements 

• personnel  limits  are  up  to  27  = NETREF  referees, 
up  to  27  = IRO  radio  operators,  and  up  to  3 = ICON 
controllers.  Up  to  9 referees  per  controller  are 
provided  for. 

• a mission  may  be  of  up  to  IH  = 12  hours  duration 

• there  are  up  to  NET  = 3 networks 

• the  number  of  message  types  described  is  up  to  7 = 

MAXIT 

• a computer  run  consists  of  NSHIFT  iterations  of 
each  mission 

• computer  and  radio  communication,  as  shown  in 
Figure  2-1,  is  included;  two-way  communication 
simulation  is  partially  possible 


Table  2-1 


Principal  Model  Subscripts 


Subscript 

Name 

Application 

Range  of 
Values 

Maximum 

Value 

CMSG 

Message  number 

1-2000 

- 

I 

Task  element 

1-10 

" 

K 

Task  analysis  number 

1-8 

IREF 

Referee  number 

1-27 

MEN(1 ) 
MEN(2) 

IRQ 

Radio  operator 

1-27 

ICON 

Controller 

1-3 

MEN ( 4 ) 

IH 

Hour  Number 

1-8 

IHMAX 

NET 

Network  number 

1-3 

MAXNET 

NEC 

Effectiveness  component 

1 - Thoroughness 

2 - Completeness 

3 - Responsiveness 

4 - Accuracy 

1-4 

IP 

Priority  number 

1-5 

II 

J 

Data  itans  comprising  message 

Level 

1 - Referee 

2 - Radio  operator 

3 - CCC 

4 - Controller 

1-10 

1-4 

JMAX 

M 

Number  men /machines 

1-59 

MEN( 1 ) 
+ 1+1 

IE 

Error  type 

1-4 

lEMAX 

+ MEN(2) 
MEN(4) 
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Procedure  for  Siuulation 


The  NETMAN  model  simulates  the  message  routing  and  processing 
procedure  by  implementing  the  following  sequence  of  operations  and  pro- 
cedures: 

1.  At  the  start  of  the  simulation,  the  characteristics 
representing  a number  of  messages  sufficient  to 
satisfy  all  requirements  for  the  mission  are  calcu- 
lated, sorted  into  order  of  time  of  arrival,  and 
stored.  Each  message  is  tagged  with  a 

• message  number 

• time  of  arrival 

• priority 

• type 

• length- referee/ radio  operator  (no.  of  characters) 

• length-controller 

• origin 

2.  The  messages  with  earliest  arrival  times  are  assigned 
to  the  referees.  These  are  processed  (simulated)  by 
the  Rs,  and  then  the  ROs  in  accordance  with  the  task, 
analyses  assigned  in  input  data  lATA  (IT,  J)[see  Ap- 
pendix]. 

3.  The  resultant  messages  are  then  to  be  processed  by 
the  CCC.  Their  times  of  arrival  at  the  CCC  are  de- 
termined by  adding  a stochastically  determined  delay 
as  a function  of  the  mean  delay  due  to  the  lines  to  the 
CCC  being  busy  (TRDEL). 

4.  The  messages  are  then  accepted  by  the  appropriate 
controller.  This  rate  of  acceptance  is  a function  of 
the  controller's  capability  to  accept  inputs  and  the 
characteristics  (length)  of  the  messages  involved. 

5.  The  controller  originates  new  messages  with  a prob- 
ability equal  to  ORIG  (1,IH)  as  given  in  input  data. 

This  sequence  is  repeated  for  each  batch  of  27  messages  to  be 
processed  until  all  messages  have  been  processed.  This  completes  a 
single  exercise  iteration.  The  entire  process  is  repeated  NSHIFT  times 
representing  the  number  of  mission  iterations  which  make  up  a NETMAN 
computer  run. 
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Overview  of  the  Siaulatioo  Model 

In  order  to  implement  the  processing  sequence,  as  described,  the 
NETMAN  model  was  designed  as  a series  of  subroutines,  each  perform- 
ing a unique  function.  Figure  2-2  presents  a macro  flow  chart  of  the  en- 
tire model.  Figure  2-2  shows  the  relationship  between  the  procedure  se- 
quences of  the  model  and  the  subroutines.  A complete  list  of  all  subrou- 
tines, together  with  a brief  comment  on  the  function  of  each,  is  given  in 
Table  2-2.  Note  that  some  subroutines  call  other  subroutines.  For  ex- 
ample, MESGEN  calls  MTYPE,  POIS,  and  all  other  subroutines  in  the 
Msg  Generation  column  of  Table  2-2.  The  main  flow  of  computation  is 
determined  by  the  principal  program,  MAIN,  which  controls  the  sequenc- 
ing between  the  major  subroutine  blocks  shown  in  Figure  2-2.  More  de- 
tailed descriptions  of  each  subroutine  are  presented  in  the  Appendix. 

Following  the  read  in  of  input  data,  the  data  are  automatically  re- 
corded in  the  print  file. 

Separate  data  sets  were  specified  in  designing  the  model  to  allow 
the  mission  analyst  (model  user)  to  make  a variety  of  simulation  runs  by 
selection  of  appropriate  data  input  for  variation. 

On-Line  Experinenter  Control 

If  experimenter  control  is  specified  [ORO(7)  = 1],  then  the  user 
of  NETMAN  will  have  certain  capability  to  modify  and  control  the  simu- 
lation model  input  data  from  an  interactive  display  and/or  typewriter 
terminal.  In  response  to  queries  from  the  computer,  the  experimenter 
can  select  input  data  categories  one  at  a time  and  then  designate  specific 
numeric  values  for  many  input  parameters  prior  to  a simulation  run.  In- 
put data  are  identified,  and  the  procedure  for  experimenter  operation  is 
specified  in  the  Appendix. 

Message  Generation  and  Representation 


I Independent  message  queues  are  generated  for  each  referee,  IQONE 

: (MSGT,  IREF,  NET),  where  MSGT  or  the  total  number  of  messages  to  a giv- 

[ en  referee  during  the  simulation  may  not  exceed  200.  These  messages  are 

generated  as  a function  oflGP(IH),  and  IGR(IH),  the  input  mean  and  stand- 
I ard  deviation  of  the  number  of  stimulus  messages  arriving  at  each  referee's 

station.  Each  stimulus  message  produces  one  or  more  network  messages 
as  a stochastic  function  of  the  input  value  of  RMPS(IT).  Message  charac- 
teristics (length,  type,  arrival  time,  etc.  ) are  generated  for  each  message 
before  the  beginning  of  each  iteration  of  the  simulation. 
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READ  INPUT  PARAMETERS  CONCERNING 
OPERATORS,  HOURS,  ERRORS,  TASKS 
SIMULATION 


CARO;  INTYPE,  INCHAR,  EFFCOM,  FREQ, 

SIMPAM,  PEOPLE,  HOUR,  ERROR,  TASK 


PRINT 

OPTION 

INPUT 


FIGURE  2-2.  MACRO  FLOWCHART  OF  NETMAN  MODEL 
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^ IS  \ 
MISSION 
ITERATION 
COMPLETE?. 


AN  ITERATION  IS  ONE  COMPLETE 
SIMULATION  UNDER  A GIVEN  SET  OF 
CONDITIONS 


A RUN  REPRESENTS  A NUMBER  OF 
SIMULATIONS  (ITERATIONS)  OF  THE 
SAME  SET  OF  CONDITIONS 


' IS 
RUN^^ 
sCOMPLETEj 


COMPUTE  SUMMARY 
STATISTICS,  RECORD  HOUR 
AND  RUN  SUMMARY  DATA 

RUNSUM 


12 


r 


Subroutine 


M 

R 

C 

s 

A 

C 

Table  2-2 

G. 

D 

1 

c 

List  of  NETMAN  Subroutines 

G 

S 

0 

S 

s 

C 

S 

E 

1 

1 

1 

0 

1 

N 

M 

0 

M 

M 

rj 

M 

E 

R 

U 

P 

U 

U 

T 

U 

0 

R 

E 

L 

E 

L 

L 

R 

L 

1 

U 

A 

F 

A 

R 

A 

A 

0 

A 

N 

T 

T 

E 

T 

A 

T 

T 

L 

T 

P 

P 

1 

R 

1 

T 

1 

1 

L 

1 

U 

U 

0 

E 

0 

0 

0 

0 

E 

0 

_L 

JL 

E 

R 

N 

JL 

R 

N 

Comment 

SIMPAM 

Read  simulation  parameters 

X 

X 

PEOPLE 

Read  operator  parameters 

X 

X 

HOUR 

Read  hour  parameters 

X 

X 

ERROR 

Read  error  data 

X 

X 

TASK 

Read  task  data 

X 

X 

EXPER 

Communicate  with  experimenter 

X 

X 

MESGEN 

Generate  all  messages 

X 

RESET 

Set  up  message  initial  conditions 

MTYPE 

Determine  message  type 

X 

POIS 

Determine  no.  of  messages  produced 

by  stimulus  message 

X 

MPRIOR 

Determine  priority  of  message 

X 

ORIG 

Determine  message  origin 

X 

DIGIT 

Determine  message  length  for  RO 

X 

CONMSG 

Determine  message  length  for  controller 

X 

MTARIV 

Determine  message  arrival  time 

X 

SORT 

Sort  messages  by  time  of  arrival 

X 

REFRE 

Process  referees 

X 

STRESS 

Compute  operator  stress 

X 

X 

X 

ASPIRE 

Compute  operator  aspiration 

X 

X 

X 

FATIGU 

Compute  operator  fatigue 

X 

X 

X 

PROG 

Simulate  message  processing 

X 

X 

X 

X 

RADOP 

Process  radio  operators 

X 

X 

BUFF 

Store  messages  into  buffer  area 

X 

CONTR 

Simulate  controller 

X 

RUNSUM 

Compute  run  summary  statistics 

X 

INIT 

Initialization  of  variables  at  start  of 

run 

CCC 

Process  computer  messages 

X 

RANDU 

Calculate  uniform  random  number  (0-1) 

X 

X 

X 

X 

X 

RANDN 

Calculate  distribution  of  random 

number 

X 

X 

X 

X 

X 

INTYPE 

Read  message  type  data 

X 

X 

INCHAR 

Read  message  length 

X 

X 

EFFCOM 

Read  effectiveness  component  data 

X 

X 

FREQ 

Read  transmission  delay  data 

X 

X 
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Each  message,  as  it  is  generated,  is  assigned  a unique  number,  CMSG, 
and  this  number  is  used  to  assess  the  message  characteristics,  MSGCHR 
(CMSG,  9)  as  the  message  passes  from  one  level  to  another  through  the 
system. 

Messages  are  represented  in  the  model  by  a series  of  the  seven 
descriptors: 

1.  cumulative  message  num.ber--a  unique  number 
assigned  to  each  message  in  order  starting  with  1. 

For  each  new  message:  CMSG  = CMSG  + 1. 

2.  message  priority--an  integer  (1  to  5)  determined 
by  generating  a pseudo  random  number  equally 
probable  in  the  range  0 to  1 (RY)  and  comparing 
its  value  against  the  five  values  of  FREP(IP,  IH)-- 
cumulative  proportion  of  the  five  types  of  message 
priorities  given  in  input.  The  value  of  priority  as- 
signed is  the  smallest  value  of  the  five  priorities. 

IP,  for  which  RY  < FREP(IP,  IH).  The  priority 
value  does  not  affect  the  simulation. 

3.  a code  indicating  one  of  seven  message  types  as- 
signed similarly  to  priorities.  Here,  the  type  is 
assigned  to  be  the  smallest  value  for  which  a new 
RY  < FRETdT,  IH),  where  FRET(IT,  IH)  provided 
as  input,  indicates  the  cumulative  proportion  of 
messages  by  the  seven  types  of  messages,  IT, 

4.  the  length  of  the  message  for  the  referee/ radio 
operator--a  function  of  the  average  number  of 
characters  in  that  type  of  message,  INC(IT),  and 
the  standard  deviation  around  that  average  INS(IT), 
both  input.  To  accomplish  this,  a random  deviate, 

RD  (mean  0,  sigma  1),  is  calculated  by  the  RANDN 
routine  and  used  in  the  equation: 

ILEN  = INC(IT)+  RD  • INS(IT) 
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5.  the  length  of  the  message  to  the  controller  is  de- 
termined through  the  equation; 

ILEN  = CHRCON(IT)+  RD  • CHSCON(IT) 

where  CHRCON(IT)  is  the  mean  length  and  CHSCON(IT) 
is  the  standard  deviation. 

6.  the  time  of  arrival  of  the  message  as  determined  by 
a stochastic  process,  where  all  times  during  the  ar- 
rival hour  are  equiprobable. 

7.  for  each  hour,  ORIGdOR,  IH),  the  message  origin 
generated  to  represent  the  source  at  each  level  of 
processing: 

lOR  = 1 for  controller 
lOR  = 2 for  other  referee 
lOR  = 3 for  current  referee 


In  the  field,  it  is  not  uncommon  that  a message  received  by  a ref- 
eree will  in  fact  generate  more  than  one  network  message,  each  of  which 
must  be  processed  by  the  operational  personnel  on  duty.  Incorporation  of 
this  feature  yields  improved  realism  and  allows  the  system  analyst  to  de- 
termine the  effect  of  the  ratio  (number  of  generated  to  input  messages)  on 
system  performance  efficiency. 

To  accomplish  this,  the  input  data,  RMPS(IT)  specifies  the  average 
number  of  messages  entered  into  the  system  as  a result  of  input  stimulus 
messages  of  each  type.  The  program  accepts  these  inputs  and  calculates 
for  each  input  stimulus  message  a value  from  a Poisson  distribution  to 
represent  the  actual  number  of  messages  to  be  processed  as  a result  of 
the  single  input  stimulus  of  type  IT:  RP[RMPS(IT)J . The  message  genera- 
tion subroutine  is  then  adjusted  to  generate  that  integer  number  of  mes- 
sages for  processing.  Each  resulting  message  is  assigned  the  same  time 
of  arrival,  as  calculated  by  MESGEN,  although  the  other  message  charac- 
teristics (priority,  type,  length)  are  calculated  independently.  Each  stim- 
ulus message  will  always  generate  at  least  one  network  message. 

During  the  MESGEN  subroutine,  a total  of  up  to  5400  messages 
may  be  generated.  These  messages  are  then  sorted  in  order  by  time  of 
arrival  for  each  referee,  and  the  model  then  is  ready  to  initiate  message 
processing  for  an  iteration. 
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Message  Processing 

The  processing  of  a single  message  by  each  referee  and  radio  oper- 
ator is  similar  in  that  each  processing  involves  the  determination  of; 

subroutine 

operator  stress  STRESS 

operator  aspiration  and  performance  ASPIRE 

operator  fatigue  FATIGU 

execution  time  and  success/failure  PROC 


Stress 


The  stress  function  is  based  on  the  concept  that  operator  anxiety  is 
a function  inversely  related  to  the  amount  of  idle  time  he  has  in  processing 
his  message  workload.  The  same  functional  relationship  is  applied  to  any 
operator--referee,  radio  operator,  or  controller- -but  not,  of  course,  to  the 
CCC.  Stress  is  operationally  defined  for  operator  M as  STR(J),  which 
assumes  a value  of  unity  for  operators  who  feel  no  anxiety  sufficient  to  af- 
fect performance.  This  condition  applies  to  all  operators  who  are  idle 
one-third  of  the  time  or  more.  The  stress  increases  linearly  with  addi- 
tional workload  until  it  reaches  a maximum  value  called  the  stress  thresh- 
old, STRM(J),  whenever  the  operator  has  on  the  average  only  three  min- 
utes per  hour  of  idle  time.  These  situations  are  shown  as  a function  of 
per  cent  time  worked,  PTW,  together  with  the  formulas,  in  Figure  2-3. 

PTW,  in  the  case  of  the  controller,  is  calculated  on  the  basis  of 
mean  message  arrival  rate  during  the  hour,  mean  time  to  process  a mes- 
sage, and  a random  deviate. 

Using  this  stress  calculation,  a normalized  stress  factor,  SF,  is 
calculated  for  use  in  performance  time  determination: 

CP  - ^ 

" STRM(J)  - 1 

This  stress  calculation  is  initiated  only  after  the  first  half  hour  of 
simulation.  During  the  first  half  hour,  the  no  stress  case  is  assumed.  In 
practice,  a stress  threshold  of  2.  3 has  been  found  to  represent  the  "aver- 
age" case.  Stress  thresholds  from  2.  1 to  2.  7 may  be  selected. 
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Aspiration 


Values  for  the  aspiration  of  each  operator  level  are  calculated 
stochastically  after  the  initialization  process  for  each  run  based  upon 
the  single  operator  input  parameter,  ASP(J).  Values  for  J = 3,  the 
CCC,  are  obviously  not  used. 

Aspiration  level  for  each  operator  represents  the  task  success 
record  that  the  operator  would  hope  to  attain,  where  success  record  is 
defined  as  the  ratio  of  the  number  of  task  element  successes  to  number 
of  attempts.  Thus,  an  operator  with  an  aspiration  value  of  1.  00  would 
aspire  to  succeed  in  every  one  of  his  task  attempts,  while  an  operator 
with  an  aspiration  value  of  0.  50  would  have  lower  motivation  and  would 
be  viewed  as  considering  a rate  of  one  successful  attempt  in  two  as  ac- 
ceptable. Levels  of  aspiration  from  0.  90  to  0.  99  have  been  found  to  be 
appropriate,  where  1.  0 represents  striving  for  absolute  perfection. 

The  model  maintains  a running  success  record  for  each  operator, 
called  a performance  value,  PERF(M).  Initially,  PERF(M)  is  set  equal  to 
his  aspiration  value  scaled  between  0 and  1.  Thereafter,  performance 
equals  the  ratio  of  number  of  critical  task  element  successes  to  the  total 
number  of  critical  task  elements  he  performs. 

Provision  is  made  to  modify  the  level  of  aspiration,  or  motivation, 
of  each  man  during  the  simulation.  This  is  done  by  initially  assigning  in-  ; 

dividual  aspiration  values,  permitting  those  values  to  affect  the  speed  of  i 

performance,  and  then  adjusting  the  aspiration  values  as  a function  of  j 

operator  success  records  and  the  amount  of  stress  being  incurred.  j 

i 

As  simulated,  level  of  aspiration  influences  working  pace  (via  a 
Pace  Adjustment  Factor)  and  is  in  turn  subject  to  the  influence  of  the  de- 
gree of  stress  the  operator  is  incurring  and  his  success  record.  The  re- 
ciprocal and  dynamic  quality  of  the  variable  as  treated  in  the  model  is 
quite  consistent  with  aspiration  level  dynamics  as  described  by  such 
writers  as  Lewin  (1942)  and  Kelley  and  Thibaut  (1954).  Considered  are: 

(a)  the  operator's  goal  discrepancy --the  difference  between  the  aspired  ^ 

success  record  and  the  actual  record,  and  (b)  the  difference  between  | 

current  stress  on  the  operator  and  the  operator's  stress  threshold.  Com-  i 

parison  of  the  goal  discrepancy  with  the  stress  differential  provides  the  ’ | 

basis  for  the  reciprocal  influences  involving  level  of  aspiration.  Four  j 

discrete  circumstances  can  exist.  J 
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Case  0 Zero  or  near  zero  goal  discrepancy 

Case  1 Positive  goal  discrepancy  (i.  e.  , aspiration 
in  excess  of  actual  performance  recorded 
and  subliminal  stress) 

Case  2 Negative  goal  discrepancy  and  subliminal 
stress 

Case  3 Positive  goal  discrepancy  and  stress  equal 
to  or  greater  than  threshold 


U 
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Case  4 Negative  goal  discrepancy  and  stress  equal 
to  or  greater  than  threshold 


Case  1 presents  a circumstance  which  will  be  recognized  as  pre- 
disposing positive  motivational  value--the  operator  is  not  performing  as 
well  as  he  would  like  to,  yet  he  is  only  mildly  stressed,  if  at  all.  The 
psychological  expectation  is  that  he  would  strive  to  perform  better,  and 
the  model  effects  this  by  generating  a Pace  Adjustment  Factor,  (PA FA), 
less  than  unity,  which  will  later  have  the  effect  of  simulating  his  work- 
ing faster.  Figure  2-4  shows  this  effect. 

Case  2 further  illustrates  the  dynamic  aspect  of  level  of  aspira- 
tion, both  as  occurring  in  life  and  as  simulated  in  the  model.  Presented 
is  a negative  goal  discrepancy,  which  means  that  performance  exceeds 
operator  aspiration,  and  stress  is  still  of  only  modest  magnitude.  Psy- 
chological theory  (e.  g.  , Deutsch,  1954)  indicates  that  under  these  con- 
ditions, the  operator  would  "raise  his  sights"  and  aspire  to  do  more, 
since  he  demonstrated  to  himself  that  he  has  easily  attained  the  initial 
level.  In  this  regard,  Krech  and  Crutchfield  (1948)  wrote: 

...a  successful  individual  typically  sets  his  next  goal 
somewhat,  but  not  too  much,  above  his  last  achievement. 

In  this  way  he  steadily  raises  his  level  of  aspiration. 

Although  in  the  long  run  he  is  guided  by  his  ideal  goal, 

...,  nevertheless  his  real  goal... is  kept  realistically 
close  to  his  present  position. 


This  process  is  simulated  in  the  model  according  to  a Monte  Carlo  pro- 
cedure, in  which  aspiration  is  increased  and  the  Pace  Adjustment  Fac- 
tor is  set  equal  to  1. 
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FIGURE  2-4.  PACE  ADJUSTMENT  FACTOR  AS  A FUNCTION  OF  ASPIRATION  AND  PERFORMANCE 


Case  3 presents  a circumstance  of  resignation.  The  operator 
is  not  performing  as  well  as  he  would  like,  but  is  incurring  stress  equal 
to  his  threshold.  Because  of  the  stress,  he  has  no  choice  but  to  accept 
his  current  performance  level.  The  model  effects  this  by  reducing  the 
aspiration  value  so  that  it  equals  the  performance  record.  The  simu- 
lated operator  has  ceased  his  upward  striving  and  avoids  the  severe 
stress  by  accepting  his  current  performance.  However,  associated 
with  the  cessation  of  upward  striving,  with  the  "edge"  off  the  individu- 
al's motivation,  one  might  expect  to  observe  the  beginnings  of  a partly 
voluntary  and  partly  involuntary  deterioration  in  performance.  This 
effect  is  simulated  in  the  model  by  generating  PAFA  > 1,  which  will 
later  have  the  effect  of  slowing  down  the  rate  at  which  the  operator 
performs  his  tasks  (see  Figure  2-4). 

In  Case  4,  current  stress  is  altered.  Specifically,  Case  4 
presents  the  circumstances  of  performance  exceeding  operator  aspira- 
tion, but  stress  being  substantial.  That  is,  the  operator  is  incurring 
severe  stress,  despite  the  fact  that  he  has  attained  the  level  of  per- 
formance he  set  for  himself.  It  seems  reasonable  that,  as  he  reviews 
his  success  record,  he  stops  "sweating  it"  quite  so  desperately  for 
he  has  demonstrated  that  he  can  attain  his  aspiration  level.  In  the  mod- 
el, this  is  simulated  by  reducing  the  operator's  current  stress  to  a val- 
ue 18  per  cent  below  the  stress  threshold. 


Fall gue 

Provision  is  made  in  the  model  to  simulate  fatigue  stress  via 
the  FATIGUE  subroutine.  The  implementation  of  this  variable  in  the 
model  is  based  upon  a study  of  fatigue  in  air  traffic  controllers  (Grandjean, 
Wotzka,  Schaad,  & Gilgen,  1970),  in  which  a number  of  measures  were 
taken  over  a 10  hour  work  period.  In  this  study,  68  air  traffic  control- 
lers were  tested  on  critical  fusion  frequency,  a tapping  test,  and  a grid 
tapping  test.  These  tests  were  administered  nine  times  within  24  hours 
over  a three  week  period.  The  results  are  shown  in  Figure  2-5.  The 
tapping  data  (equally  weighting  the  two  tapping  tests)  were  converted  to 
a percentage  of  baseline  plot  and  are  shown  as  the  heavy  line  in  Figure 
2-6.  As  can  be  seen,  the  trend  is  a very  slow  dropoff  up  to  six  hours 
after  starting  work,  followed  by  a more  abrupt  dropoff.  Although  the 
available  data  only  extend  through  a 10  hour  period,  the  extreme  linear- 
ity of  the  data  allow  some  degree  of  confidence  in  extrapolation  through 
12  hours. 
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2nd  4th  6lh  8th  lOth 
HOURS  AFTER  STARTING  THE  WORK 

NUMBER  OF  SUBJECTS:  67  65  64  66  66  67  50  58 

FIGURE  2-5.  MEAN  VALUES  OF  CRITICAL  FUSION  FREQUENCY, 
OF  A TAPPING  AND  OF  A GRID  TAPPING  TEST  IN 
RELATION  TO  HOURS  AFTER  STARTING  WORK 
(FROM  GRANDJEAN  ET  AL,  1970) 


RECIPROCAL  OF  PACE  ADJUSTMENT  FACTOR  DUE  TO  WORK  FATIGUE  = PAFW1 


Thus,  the  degrading  effects  of  operator  work  fatigue  are  con- 
sidered in  the  model  to  build  as  a function  of  the  length  of  time  elapsed 
since  the  shift  began,  regardless  of  the  level  of  work  activity.  To  this 
end,  a Pace  Adjustment  Factor  due  to  work  fatigue,  PAFW,  is  calcu- 
lated in  accordance  with  the  data  shown  in  Figure  2-6.  Since  the  deg- 
radation is  minimal  for  the  first  six  hours,  the  fatigue  effects  for  the 
first  six  hours  are  not  considered  within  the  model.  Thus,  only  the 
fatigue  effects  which  accrue  after  six  hours  of  work  are  considered. 
Although  only  part  of  one  day  of  a mission  may  be  simulated  in  any  one 
run,  the  model  provides  for  fatigue  degradation  effects  of  the  same 
slope  but  starting  earlier  in  the  shift  for  successive  days  of  the  mis- 
sion. Two  other  sample  day  effects  (days  5 and  9)  are  also  shown  in 
Figure  2-6. 

Operator  Processing  Time 

The  Operator  Processing  Subroutine  (PROC)  is  a miniature 
model  of  the  type  described  by  Siegel,  Wolf,  and  Leahy  (1972),  Its 
logic  flow  diagram  is  presented  in  the  Appendix.  This  subroutine 
utilizes  one  of  up  to  eight  (K)  task  analyses  appropriate  to  the  man  be- 
ing simulated  and  steps  him  through  a series  of  task  elements  to  ac- 
complish the  simulation  of  a man  processing  a message. 

For  the  messages  not  rejected,  the  stress  time  adjustfnent  fac- 
tor, ZIF,  is  calculated.  A cubic  equation  to  simulate  the  effect  of  stress 
on  performance  time  is  used.  The  function  is  presented  in  Figure  2-7. 
The  factor  equals  1.  0 if  there  is  no  stress  and  decreases  to  a value  of 
0,  292  when  current  stress  equals  the  input  parameter  stress  threshold 
for  the  man  being  simulated. 

A value  for  the  actual  time  required  for  an  operator  to  com- 
plete each  task,  TIME,  is  calculated  stochastically  as  a function  of  the 
stress  and  the  average  time  for  this  task  and  its  standard  deviation, 
AVGTMd,  K)  and  SIGMA(I,  K). 

For  the  no  stress  condition,  PTW  < 66.  6 and  STR(M)=  1.  0,  TIME 
is  the  product  of  the  operator  speed  factor,  F(J),  provided  as  input,  and 
the  value  V = AVGTMd,  K)+  RD  • SIGMA(I,  K),  where  RD  is  a random 
deviate,  calculated  from  an  initial  input  value,  RY,  each  time  required. 
The  speed  factor,  F(M),  is  intended  to  summarize  and  represent  individu- 
al differences  which  determine  how  quickly  an  individual  performs  a job. 
Speed  of  event  performance  is  treated  in  the  model  independently  from 
the  accuracy  of  performance.  Each  network  level,  J,  of  the  simulated 
system  is  initially  assigned  a value  to  represent  speed.  F(J)  is  scaled 
from  0.  8 to  1.2.  A level  assigned  an  F(J)  of  1.2  is  about  20  per  cent  slow- 
er than  average  and  a level  assigned  a value  of  0.  8 is  about  20  per  cent 
faster  than  average. 
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For  the  case  in  which 


stress  equals  the  threshold  95  < PTW  < 100, 


TIME 


F(J)  • V 
0,  292 


based  on  the  evaluation  of  the  cubic  stress  function  when  STR(M)=  STRM(M). 


When  stress  falls  between  0 and  1, 

TIME  = F(J)  • V • ZIF 

where  the  cubic  stress  function  ZIF  = 1.  829(SF)®  + 3.  472(SF)*  - 2.  351(SF)  + 1, 
shown  in  Figure  2-7. 

Thus,  in  the  simulation,  the  general  influence  of  stress  is  to  increase 
the  operator's  working  pace.  (This  is  done  by  using  ZIF  as  a multiplicative 
factor.  ) This  is  consistent  with  most  views  of  emotional  reactions  as  gear- 
ing the  individual  for  overt  activity. 

If  the  task  element  represents  an  operator  decision  [TYPE(I,  K)  = 3] , 
the  next  task  element  I is  calculated  on  the  basis  of  the  outcome  of  com- 
paring a pseudo  random  number  RY  against  AVPROBd,  K).  The  two-way 
decision  has  the  effect  of  taking  task  element  IJS(I,  K)  next  with  probabil- 
ity equal  to  AVPROBd,  K).  Otherwise,  task  element  IJFd,  K)  is  selected. 

If  the  task  element  is  an  "equipment  only  action,  " then  the  elapsed 
time  that  the  equipment  takes  to  accomplish  the  task  element  is  calculated 
without  any  effect  of  stress. 


The  following  calculations  for  the  number  of  unnoted  errors,  task 
element  execution  time,  task  element  success  determination,  bookkeep- 
ing for  time,  and  next  task  element  determination  are  repeated  for  each 
task  element  in  the  selected  sequence. 


Errors  may  be  made  by  any  of  the  men  who  participate  in  the 
mission  simulated.  Errors  are  counted  when  an  incorrect  act  is  not 
noticed  or  corrected  when  it  is  performed.  The  total  number  of  these 
unnoted  errors,  TNUE,  is  calculated  as  a Poisson  distribution  function 
with  mean  equal  to  the  product  of  the  error  rate  per  character,  the  length 
of  the  message,  and  the  operator  accuracy  (precision)  for  the  task  ele- 
ment representing  the  transform  operation,  as  follows; 
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TNUE 


S RP[ER(IE,  IT) 
IT 


ILEN 

100 


PREC(J) 


where: 


TNUE 

RP 

ER 

ILEN 

PREC(J)  = 


total  number  of  undetected  errors 
Poisson  distributed  variable 
error  rate 

no.  of  characters  in  the  message 
operator  precision 


All  other  task  elements  will  either  generate  one  unnoted  error  or  no  er- 
rors, depending  on  the  undetected  error  probability  (task  analysis  input) 
and  the  operator  precision  (operator  parameter). 

There  are  two  Pace  Adjustment  Factors  which  generate  an  influ- 
ence on  performance  time.  The  effect  of  fatigue  is  accomplished  using 
PAFW,  as  shown  in  Figure  2-6.  The  factor  for  aspiration,  PAFA,  has 
no  effect  in  aspiration  cases  0,  2,  and  4;  its  effect  in  cases  1 and  3 is 
presented  in  Figure  2-4.  The  simulated  performance  time  for  the  task 
element  is  then  the  product  of  V with  the  other  factors  F(J),  PAFW,  and 
PAFA. 


In  cases  for  which  the  average  execution  time  represents  a per- 
character  time  (i.  e.  , if  the  task  element  is  one  for  which  .ITYPE  (I,  K) 

= 2),  then  the  total  time  of  the  task  element  as  determined  is  multiplied 
by  the  number  of  characters  in  the  message. 

As  each  task  element  is  completed,  a determination  is  made  as 
to  whether  one  of  the  basic  time  segments  of  message  processing  has 
been  completed.  Up  to  2 0 time  segments''' may  be  accumulated  and  then 
summarized  in  the  RUNSUM  subroutine.  The  segment  being  ended  is  in- 
dicated in  the  input  data  in  END(I,  K). 


Task  Element  Success  Probability 

Next,  the  success  or  failure  of  the  task  element  is  determined 
as  a function  of  the  input  task  element  average  probability  of  success, 
AVPROBd,  K),  the  current  stress  value,  the  stress  threshold,  and  pre- 
cision. 


A segment  is  any  point  in  a task  analysis  relative  to  which  the  user 
wishes  to  collect  data. 


First,  the  average  success  probability  input  value  is  operated 
on  by  the  current  value  of  operator  precision  (an  input  parameter),  as 
shown  in  Figure  2-8.  This  figure  shows  how  the  AVPROB(I,  K)  value 
is  adjusted  from  one  shown  on  the  Y axis  (as  input  to  the  model)  to  a 
new  value  as  shown  on  the  X axis  as  a function  of  the  value  of  PREC(J) 
Sample  PREC(d)  values  are  shown.  Note  that  no  change  takes  place  if’ 
REC(J)  equals  1.  A degradation  of  success  probability  results  for 
values  of  PREC(J)  greater  than  1.  0.  The  opposite  effect  is  achieved 
or  lower  PREC(J)  values,  and  all  task  elements  will  succeed  with  cer- 
tainty if  PREC(J)  equals  or  is  less  than  0.  8.  Note  that  in  the  model 
operator  precision  and  speed  are  completely  independent  input  param- 
eters. 


The  result  of  this  adjustment  is  used  in  success  determination 
as  shown  in  Figure  2-9.  If  stress  is  relatively  small  (i.  e. , less  than 
one- half  of  the  t*-  shold  value),  or  if  the  current  aspiration  is  less 
than  the  adjuster  'OB (I,  K)  value,  then  that  probability  value  is  used 
as  the  fraction  ag^.mst  which  a pseudo  random  number  (RY)  is  com- 
pared to  determine  success  or  failure.  Success  is  the  result  if  the  RY 
selected  is  the  lesser.  Thus,  in  this  nominal  case,  success  will  occur 
with  probability  equal  to  the  average  input  value. 

If  stress  is  higher  than  one-half  of  but  does  not  exceed  the  thresh- 
old, and  if  current  aspiration  exceeds  AVPROB(I,  K),  then  a linearly  in- 
creasing function  is  used  to  determine  the  function  against  which  RY  is 
compared.  This  function,  shown  in  Figure  2-9,  is  principally  depend- 
ent on  stress. 

If  stress  exceeds  the  threshold,  then  the  aspiration  value  is  used 
as  the  fraction  against  which  RY  is  compared,  so  that  the  success  rate 
in  the  long  run  will  equal  the  aspiration. 

In  each  case,  the  success/failure  indicator,  SIF,  is  set  to  S or  F 
as  appropriate,  and  the  processing  continues. 

The  current  operator  time  of  day  Z(M)  and  the  total  time  worked 
TW(IH,  M)  are  then  adjusted  as  a result  of  the  time  worked  on  this  task 
element. 
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FIGURE  2-9.  SUCCESS  PROBABILITY  CRITERIA  AS  A FUNCTION  OF  STRESS 


Next,  determinations  are  made  of  the  next  task  element  to  be 
performed,  and  a count  is  kept  of  the  number  of  successful  and  unsuc- 
cessful task  elements  for  use  in  calculating  performance.  If  the  com- 
pletion of  this  task  element  ran  over  into  the  next  hour,  the  message 
processing  results  for  the  current  hour  are  separated  and  appropriate 
message  and  task  data  are  retained  for  the  next  hour. 

Task  element  results  are  then  recorded  if  ORO(5)  has  a value 

of  1. 

This  entire  procedure,  controlled  by  the  PROC  subroutine,  is 
repeated  for  all  task  elements  in  the  task  analyses  list  selected.  In 
accordance  with  IJS(I,  K)  and  IJF(I,  K)  values  and  success  or  failure 
outcomes  of  task  elements,  this  sequence  can  be  linear  (i.  e.  , straight 
sequential)  or  can  include  skips  and  loops. 

Information  Loss 

Following  completion  of  operator  task  element  processing,  con- 
trol returns  to  the  main  routine  where  a variable  called  the  information 
loss  (INFOLS)  is  calculated.  Information  loss  is  directly  proportional 
to  the  total  number  of  characters  in  the  message.  Information  loss  is 
also  a function  of  the  probabilities  of  errors  going  unnoticed  in  the  CCC 
data  base.  Such  errors  of  significant  importance  (probability  = PUS)  are 
weighted  ten  times  more  heavily  than  those  of  little  importance  (prob- 
ability=  PUL).  When  the  INFOLS  is  less  than  one,  it  is  set  at  zero  and 
reported  accordingly: 

INFOLS  = (10  PUS+  PUL)  X ILEN 

where; 

PUS  = probability  of  a significant  error 
PUL  = probability  of  an  insignificant  error 
ILEN  = message  length 

Effectiveness  Measures 

Baker  (1970)  defined  four  system  performance  measures--thorough- 
ness,  completeness,  responsiveness,  and  accuracy.  For  the  model,  each 
of  these  was  framed  in  terms  of  an  output  calculation  and  were  combined 
into  a single  efficiency  function  and  averaged  over  the  run  as  a summary 
of  performance. 

Each  component  as  well  as  the  total  effectiveness  is  scaled  in  the 
range  from  zero  to  one. 


J 


The  first  effectiveness  component,  EC(1),  representing  thor- 
oughness, is  the  ratio  of  the  number  of  messages  completed  during 
the  hour  by  a controller  divided  by  the  number  of  messages  arriving 
during  the  hour.  The  second  component,  completeness,  EC(2),  is  de- 
fined as  the  mean  of  performance,  PERF(J),  values  summarized  over 
all  men  (performance  represents  the  percentage  of  successful  task 
elements). 

The  third  component,  responsiveness,  is  determined  as; 


EC(3)  = 


average  message  processing  time  from 

referee  start  to  controller  end 

average  total  elapsed  message  time 
(including  idle  periods) 


Accuracy  is  determined  from  the  relationship; 


EC  (4)  = 1 - 


Total  information  loss 

Number  of  messages  completed 


where  total  information  loss  is  the  sum  of  INFOLS  values  over  all  mes- 
sages for  the  hour.  Responsiveness  will  then  approach  perfection  as 
information  loss  approaches  zero.  All  components  are  upper  limited  at 
1.  0 and  lower  limited  at  0.  0. 

Though  two  of  the  four  factors  are  changed,  the  global  effective- 
ness measure  is  calculated  as  in  the  model  described  by  Siegel,  Wolf, 
Leahy,  and  Bearde  (1973); 


„„„  |CC12)*  + (CC13)2+  (CC14)2  + (CC23)^  + (CC24)^  + (CC34)^  | 

EFS=  g -J* 

[W(1)EC(1)+  W(2)EC(2)+  W(3)EC(3)+  W(4)EC(4)] 

^ p - (CC12)^  + (CC13)^  + (CC14)^  + (CC23)^  + (CC24)^  f (€034)^"!  ^ 


[EC(1)'^^^^][EC(Z)''^^^^][EC(3)^^^^][EC(4)^^^^] 


where: 


EFF  = 
CC12  = 
CC13  = 
CC14  = 
CC23  = 
CC24  = 
CC34  = 
W(IC)  = 
EC(1)  = 
EC(2)  = 
EC(3)  = 
EC(4)  = 


effectiveness 

correlation  between  thoroughness  and  completeness 

correlation  between  thoroughness  and  responsiveness 

correlation  between  thoroughness  and  accuracy 

correlation  between  completeness  and  responsiveness 

correlation  between  completeness  and  accuracy 

correlation  between  responsiveness  and  accuracy 

weight  for  each  component 

thoroughness 

completeness 

responsiveness 

accuracy 


Co  mputer  and  Co  ntroller  Delay 

Within  the  processing,  delay  times  for  the  computer  and  the  control- 
lers are  calculated  in  accordance  with  an  equation  developed  by  Karlin  (1969). 
These  delay  times  are  calculated  as: 

Q = G/(UM-G) 

CALL  POIS  (Q,  RY,  KK) 

where; 

UM  = 1/ (average  time  to  process  a message) 

G = (total  messages  per  hour)/ 3600 


The  value  Q is  used  as  the  mean  of  a poisson  distribution  with  a ran- 
dom number  generation  routine  to  stochastically  determine  KK,  the  number 
of  messages  residing  in  queue  when  the  current  message  arrives.  The  max- 
imum allowed  number  of  messages  is  upper  limited  at  the  number  which 
would  be  performed  on  one -half  hour.  Once  KKK  is  determined,  this  value 
is  used  in  connection  with  the  mean  time  per  message  to  determine  stochasti- 
cally the  delay  time  required  before  the  current  message  is  processed. 

The  time  to  process  a message  as  used  in  the  calculation  of  UM  is 
determined  from  the  task  analysis  with  the  assumption  that  task  elements 
which  are  failed  will  be  repeated  until  successful: 


TPMC(K)=  TPMC(K)+  AVGTM(I,  K)/AVPROB(l,  K) 


1 


Results  Recording 

In  addition  to  the  tabulated  listing  of  model  inputs,  there  are  three 
principal  forms  of  output  generated  by  the  NETMAN  model.  These  are: 

• the  detail  results  from  simulation  of  individual  mes- 
sages by  individual  operators.  This  output  presents 
extreme  detail  and  its  availability  is  optional  under 
control  of  ORO(5) 

• the  end-of-hour  report,  showing  results  of  per- 
formance by  operator  type  for  each  hour  across 
all  iterations 


• the  run  summary  report,  showing  summaries 
across  hours 


Sample  output  listings  for  each  of  these  three  categories  are  shown 
in  Figures  2-10,  2-11,  and  2-12,  respectively. 
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Figure  2-10.  Sample  detail  results. 
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III.  SENSITIVITY 


Having  developed  the  model  in  the  form  described  in  Chapter  II, 
a set  of  computer  runs  was  completed  to  assess  the  rationality  and  sensi- 
tivity of  the  NETMAN  model  to  input  variation.  While  such  tests  provide 
no  information  relative  to  the  predictive  validity  of  the  model,  the  results 
of  such  tests  allow  initial  evaluation  of  the  model  from  the  point  of  view  of 
t the  logicalness  of  its  output. 

Four  input  variables  were  manipulated  in  these  sensitivity  tests: 

' operator  speed,  operator  precision,  message  frequency,  and  message 

length.  These  were  selected  because  of  their  saliency  in  system  per- 
formance. The  model  input  data  used  in  the  sensitivity  evaluation  are 
; shown  in  Figure  3-1. 

I 

The  variations  introduced  into  the  Figure  3-1  data  to  test  the  sensi- 
tivity of  NETMAN  are  shown  in  Table  3-1 


RUN 

Number 

1 

2 

3 

4 

5 

6 

7 

8 


Table  3-1 


Summary  of  Sensitivity  Test  Runs  Completed 


Parameter (s)  Changed 


See  basic  input 
All  operators  precision=  1.1 
All  operators  precision=  0.9 
All  operators  speed=  0.7 
All  operators  speed=  0.9 
All  operators  speed=  1.1 

Referee/radio  operator's  message  length  22  characters 
Referee/radio  operator's  message  length  11  characters 
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Results 


On  the  general  level,  the  sensitivity  tests  indicated  reasonable  mod- 
el output  and  acceptable  directional  response  to  input  variation.  The  results 
seem  intuitively  reasonable  and  appropriate  for  message  processing  eval- 
uation relative  to  field  exercises. 

Speed 

Figure  3-2  summarizes  the  message  processing  time  results  when 
operator  speed  was  varied  from  0.  7 (fast)  to  1.  1 (slow).  The  anticipated 
directional  trend  is  clearly  evident.  Processing  time  refers  to  time  actu- 
ally spent  working  on  messages  suid  does  not  include  message  time  in  queue 
The  average  processing  time  was  derived  by  dividing  the  total  amount  of 
time  worked  by  the  number  of  messages  processed.  With  the  very  fast 
crew  [F(J)  = 0.  7]  mean  working  time  was  272  seconds  per  message.  Vi  hen 
simulated  crew  speed  was  degraded  to  the  F(J)  = 1.  1 level,  an  increase  of 
77  per  cent  (average  time  per  message  = 481  seconds)  of  working  time  was 
indicated  for  each  message. 

Figure  3-3  shows  the  mean  total  message  handling  time  (i.  e. , in- 
cluding both  working  and  queuing  time)  for  each  of  four  operator  speeds. 
The  effect  of  operator  speed  on  total  message  handling  time  was  larger 
than  the  effect  on  processing  time,  and  again  the  anticipated  trend  was  evi- 
denced. The  fastest  simulated  team  required  630  seconds  to  handle  a 
message  as  opposed  to  3793  seconds  for  the  slowest  simulated  team.  This 
represents  an  increase  in  handling  time  of  502  per  cent  and  an  increase 
in  queuing  time  of  825  per  cent: 


Speed 

Handling 

Working 

Queuing 

. 7 

630 

2 72 

358 

1.  1 

2008 

367 

3312 

3312-358 

= 8.25  X 

100  = 825% 

358 

Accordingly,  within  the  simulation,  slower  operators  produced  a 
realistic  chain  effect  of  longer  message  waiting  in  a queue  before  process- 
ing. The  effect  of  slower  workers  in  a chained  type  system  was  indicated 
to  be  greater  than  would  be  predicted  by  their  slowness  alone.  This  effect 
seems  quite  reasonable  and  is  most  evident  in  a high  workload  situation 
such  as  the  current  test  runs. 
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MEAN  TOTAL  MESSAGE  PROCESSING  TIME  (SECS.) 


The  effects  of  operator  speed  on  the  overall  system  effectiveness 
measure,  as  indicated  by  the  sensitivity  tests,  are  presented  in  Figure 
3-4.  The  fastest  simulated  [F(J)  = 0.  7]  team  was  indicated  to  have  the 
best  overall  effectiveness  (.  84).  This  result  is  in  agreement  with  the 
message  time  data  described  above.  The  simulated  extremely  slow 
team's  overall  effectiveness  was  indicated  to  be  marginal  (.  66).  Ac- 
cordingly. the  sensitivity  test  results  indicate  the  effectiveness  meas- 
ure to  be  sensitive  to  the  operator  speed  variable. 

The  overall  effectiveness  index  is  based  on  a weighted  composite 
of  the  four  effectiveness  components:  thoroughness,  responsiveness, 
completeness,  and  accuracy.  Of  the  four,  the  thoroughness  and  the  re- 
sponsiveness components  are  most  directly  related  to  operator  speed, 
while  the  completeness  and  the  accuracy  components  are  more  directly 
related  to  errors.  Thoroughness  is  essentially  a measure  of  the  num- 
ber of  messages  processed  compared  to  the  number  which  should  have 
been  completed.  The  responsiveness  component  is  based  on  the  ratio  of 
message  processing  (actual  work)  time  to  total  throughput  time. 

The  obtained  results  relative  to  the  effects  of  operator  speed  on 
the  thoroughness  component  are  presented  in  Figure  3-5.  While  the  an- 
ticipated directional  trend  is  indicated  in  Figure  3-5,  the  maximum  ob- 
tained thoroughness  value  was  only  . 56.  This  is  due  to  the  very  heavy 
heavy  simulated  message  load  in  the  present  simulations.  In  the  case 
of  the  slow  operator  working  speed  [F(J)  = 1.  1],  thoroughness  dropped 
to  .22. 


The  obtained  relationship  between  operator  speed  and  the  respon- 
siveness component  is  shown  in  Figure  3-6.  Again,  the  anticipated  direc- 
tional trend  was  indicated.  The  fastest  simulated  team's  responsiveness 
index  was  . 94,  while  for  the  slowest  team  the  index  fell  to  . 81. 


Precision 

Precision  was  the  other  major  operator  parameter  varied  in  the 
present  set  of  sensitivity  tests.  Precision  is  the  humanistic  variable  in 
the  model  which  reflects  errors.  A more  precise  operator  team  will 
commit  fewer  errors.  Since  errors  impose  a requirement  for  task  repe- 
tition or  for  canceling  part  of  work  already  completed,  errors  are  time 
consuming.  Additionally,  errors  which  are  not  detected  will  eventuate  an 
incorrect  or  incomplete  message--degrading  system  performance. 
cision  can  be  varied  independently  within  the  model  and  was  so  varied  for 

the  sensitivity  tests. 
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0,7  0.8  0.9  1.0  1.1 

OPERATOR  SPEED,  F(J) 

FIGURE  3-4.  SYSTEM  OVERALL  EFFECTIVENESS  AS  A FUNCTION  OF 

OPERATOR  SPEED 


SLOW 
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0.7 


0.8 


0.9 


1.0 


1.1 


OPERATOR  SPEED,  F(J) 

FIGURE  3-5.  THE  EFFECT  OF  OPERATOR  SPEED  ON  THOROUGHNESS 
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RESPONSIVENESS 


Figure  3-7  presents  the  effects  of  precision  variation  onprocessing 
time.  Processing  time  which,  as  indicated  earlier,  represents  actual 
working  time,  was  326  seconds  for  the  highly  precise  network  team  and 
increased  at  a positively  accelerated  rate  to  627  seconds  for  the  most  er- 
ror prone  simulated  team.  This  represents  an  increase  (i.  e.  , decrement) 
from  baseline  [P(j)  = 1.  0)  of  71  per  cent,  while  the  results  for  the  more 
precise  team  represent  a savings  of  11  per  cent  over  the  baseline  team. 


Totsil  message  handling  time,  as  shown  in  Figure  3-8,  also  showed 
a positively  accelerated  increase  as  precision  was  degraded.  The  results 
for  the  more  accurate  team  [P(J)  = 0.  9]  indicated  a 44  per  cent  margin  over 
the  baseline  team,  while  the  results  for  the  lowest  precision  simulated  team 
(Pj  = 1,  1)  indicated  a 136  per  cent  deficit  (i.  e. , increase  in  handling  time). 
A comparison  of  the  performance  of  the  most  precise  team  with  that  of  the 
least  precise  simulated  team  indicated  that  the  least  precise  team  spent  92 
per  cent  more  working  time  on  each  message  and  321  per  cent  more  time 
in  message  handling.  As  was  indicated  in  the  case  of  operator  speed,  in- 
creases in  working  time  were  accompanied  by  a much  larger  increase  in 
queue  waiting  time  (814  per  cent  in  the  current  case).  Again,  the  bottle- 
neck situation,  in  which  the  network  speed  is  determined  by  the  poorest 
(or  most  error  prone  in  this  case)  chain  within  the  network  was  indicated. 


The  effect  of  precision  variation  on  overall  effectiveness  is  shown 
in  Figure  3-9.  Again,  the  desired  directional  trend  was  indicated  by  the 
model's  output.  Comparison  of  the  data  of  Figure  3-9  with  the  parallel 
plot  for  speed  (Figure  3-4)  indicates  that  with  everything  else  held  con- 
stant, a precision  of  0.  9 produced  an  overall  effectiveness  of  value  . 81, 
while  a speed  factor  of  0.  9 produced  an  effectiveness  of  . 78.  Similarly, 
the  1.  1 precision  value  produced  an  overall  effectiveness  of  . 58,  while 
a speed  of  1.  1 produced  an  effectiveness  of  . 66.  Accordingly,  the  over- 
all effectiveness  value  seems  more  sensitive  to  precision  variation  than 
to  simulated  operator  speed  variation.  Such  a tendency  seems  entirely 
reasonable  since  some  degree  of  slowness  can  usually  be  tolerated  to  a 
greater  extent  than  the  same  degree  of  inaccuracy. 


MESSAGE  HANDLING  TIME  (SECS.) 


f 


Figure  3-10  shows  the  obtained  completeness  index  as  a function 
of  operator  precision.  Here,  as  in  the  time  curves,  a curvilinear  decre- 
ment was  indicated  as  a function  of  decreasing  precision.  A range  of  .29 
effectiveness  points  was  indicated  between  the  lowest  and  the  highest  error 
producing  groups. 

Simulated  operator  speed  is  directly  related  to  the  thoroughness 
component.  However,  because  precision  effects  time  by  requiring  touch 
ups  and  task  repetition,  we  would  also  expect  precision  to  have  an  effect 
on  thoroughness.  Figure  3-11  presents  this  relationship  and  indicates 
that  the  anticipated  directional  relationship  was  yielded  by  the  sensitivity 
tests. 

Responsiveness,  as  shown  in  Figure  3-12,  was  also  strikingly  af- 
fected in  the  anticipated  direction.  A drop  of  .27  effectiveness  points  was 
indicated  as  simulated  operator  precision  was  varied  between  0.  9 and  1.  1. 
The  rate  of  responsiveness  drop  was  greater  compared  with  the  . 09  and 
1.  0 teams. 

Accordingly,  within  the  stochastic  simulation  model,  precision 
seems  to  be  a primary  factor  affecting  the  calculated  system  effectiveness. 
The  test  results  suggest  that  for  systems  such  as  that  simulated,  the  re- 
sult of  allowing  error  prone  teams  to  operate  the  system  is  to  grossly  de- 
grade network  performance.  The  sensitivity  test  results  suggest  the  im- 
portance of  maintaining  at  least  minimum  performance  standards  for  sys- 
tem personnel  and  the  model  seems  quite  sensitive  to  these  effects. 


Message  Length 

Message  length  for  the  referee/radio  operator  messages  was  simu- 
lated in  the  sensitivity  tests  at  11,  17,  and  22  characters.  The  22  charac- 
ter messages  required  somewhat  longer  processing  time  than  the  17  char- 
acter baseline  (441  versus  367  seco.nds)  messages.  However,  the  other 
comparisons  produced  little  or  mixed  effect  which  can  be  attributed  to  ran- 
dom variation.  The  difference  between  handling  a message  of  1 1 charac- 
ters and  one  of  22  characters  only  amounts  to  a few  seconds.  Accordingly, 
in  view  of  the  limited  message  length  range  simulated,  little  effect  of  mes- 
sage length  may  have  been  anticipated.  At  any  rate,  within  the  range  of 
the  tests  performed,  the  model  seems  more  sensitive  to  operator  oriented 
variables  than  to  message  length. 
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IV.  SUMMARY  AND  DISCUSSION 


The  NETMAN  model  was  designed  to  allow  simulation  of  message  ; 

processing  in  a system  composed  of  up  to  three  networks.  Each  network  s 

may  be  composed  of  up  to  nine  referees,  up  to  nine  radio  operators,  and  ] 

one  controller.  One  computer  is  assumed  to  accommodate  the  three  net-  I 

worKs.  As  such,  the  model  allows  simulation  and  test  of  the  effects  on  ' 

system  effectiveness  of  varying  such  aspects  as:  number  of  referees,  - 

number  of  networks,  task  procedures,  message  arrival  rate,  message  ' 

length,  and  operator  skill. 

I 

The  results  of  the  simulation  are  interpretable  in  terms  of  a num-  ! 

ber  of  formal  effectiveness  measures  (accuracy,  thoroughness,  respon- 
siveness, completeness)  and  an  overall  effectiveness  index.  Additional-  ' 

ly,  the  results  are  interpretable  in  terms  of  such  model  results  as  work  t 

time,  stress  imposed,  message  processing  time,  errors,  number  of  mes-  ■ 

sages  processed,  and  fatigue.  ] 

NETMAN,  in  a sense,  represents  a second  generation  development  | 

since  many  of  its  subroutines  are  based  on  and  drawn  from  subroutines  ; 

included  in  stochastic  models  previously  developed  by  the  Army  Research  < 

Institute  for  the  Behavioral  and  Social  Sciences.  As  such,  some  confi-  ' 

dence  can  be  placed  in  the  results  of  the  simulation.  However,  a need  ; 

for  independent  validation  of  the  present  model  exists. 

The  results  of  the  sensitivity  tests  suggest  that  the  data  obtained 
from  NETMAN  are  directionally  logical  and  that  the  output  is  sensitive 
to  input  variation.  To  this  extent,  a workable  model  can  be  said  to  have 
been  achieved. 

From  the  point  of  view  of  operator  performance  analysis,  the  mod- 
el is  believed  to  be  highly  flexible.  The  analyst  may  vary  operator  charac- 
teristics and,  through  task  analytic  input,  the  characteristics  of  the  work 
performed  by  each  operator.  Accordingly,  a wide  variety  of  "experiments" 
may  be  performed  by  the  analyst  to  determine  optimum  conditions. 

If  agreement  of  the  results  from  such  a model  with  parallel  field 
exercises  can  be  shown,  then  considerable  savings  can  be  introduced  by 
substituting  model  simulated  "exercises"  for  field  exercises.  It  should 
be  possible  for  the  model  to  yield  results  in  a few  hours  which  would  re- 
quire weeks  of  time  and  teams  of  personnel  in  the  actual  exercise  situa- 
tion. Moreover,  due  to  the  interactive  (remote  terminal)  feature,  the 
completion  of  such  stochastic  simulations  is  highly  convenient. 
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The  structuring  built  into  the  computer  program  should  allow  ad- 
dition of  new  subroutines,  if  warranted,  without  undue  difficulty.  Similar- 
ly, modifications  within  any  individual  subroutine  are  believed  practical. 

Both  the  user  and  the  model's  developers  should  collaborate  in  the  design 
and  implementation  of  such  modifications. 

We  do  not  contend  that  the  NETMAN  model  can  directly  solve  oper- 
ational problems.  Similarly,  operational  exercises  may  or  may  not  pro- 
vide solution  avenues  relative  to  true  operational  problems.  But,  the 
simulation  should  normally  provide  clean  and  clear  indications.  Such 
indications  may  be  confounded  in  operational  exercises.  The  stochastic 
model  can,  presumably,  capture  the  core  of  a problem  and  set  it  in  a 

form  in  which  it  can  be  understood.  : 

Finally,  we  note  that  NETMAN  like  any  stochastic  model  may  tell 
the  user  what  will  happen  to  a system  "on  the  average.  " However,  the  of- 
ficer in  the  field  will  be  little  overjoyed  to  know  something  about  averages.  ‘ 

He  wants  to  know  whether  current  information  has  entered  and  been  con- 
solidated by  the  system  network.  The  average  will  be  of  little  use  to  him 
tactically,  although  it  may  be  very  satisfying  statistically.  And,  the  per- 
son who  is  wounded  because  of  an  information  flow  bottleneck  will  find  I 

little  comfort  in  knowing  that  he  is  incapacitated  because  of  a situation  1 

which  is  really  three  standard  deviations  from  the  mean.  j 
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The  simulation  model,  NETMAN,  is  controlled  primarily  by  card 
input  but  the  capability  for  changing  parameters  in  the  real  time 
mode  is  provided.  Table  1 shows  the  required  card  input  sequence 
This  sequencing  must  be  adhered  to.  The  "card  types"  from  1 to  18 
refer  to  the  order  and  format  requirements  for  each  type  of  input 
data. 


Card  Types  1 , 2 , and  3 


Table  2 shows  the  card  column  requirements  for  card  types 
1 to  3.  These  data  (as  well  as  card  type  4)  are  read  in  and  pro- 
cessed in  subroutine  SIMPAM. 


The  first  data  card  is  used  for  simulation  identification 
purposes.  The  (up  to  72  character  long)  prose  descriptor  identifica- 
tion information  will  be  printed  at  the  top  of  each  page  of  print- 
out. A unique  title  is  recommended  for  each  simulation  to  prevent 
confusing  similar  simulation  runs.  A blank  card  may  be  used  if  no 
identification  information  is  desired. 


The  major  simulation  parameters  are  identified  on  card  type  2. 
The  number  of  simulation  iterations ,NSHIFT , is  the  first  entry.  A 
value  of  at  least  30  is  recommended.  In  the  case  of  simulations 
with  many  low  probability  events,  100  or  more  iterations  will  be  re- 
quired in  order  to  produce  stable  output. 


The  number  of  hours  over  which  statistics  will  be  generated  is 
indicated  by  the  variable  IHMAX.  This  value  is  entered  into 
columns  4-6  on  card  type  2.  The  maximum  value  for  IHMAX  is  12  as 
shown  in  Table  3.  The  limits  shown  in  Table  3 are  set  by  the 
current  storage  allocation  in  the  computer  program. 

The  maximum  number  of  message  types;  MAXIT,  is  limited  by 
current  dimensioning  to  7.  Message  type  is  used  to  specify  the 
task  procedure  to  be  used,  the  message  length,  and  relative  frequency. 


Table  1 


Card 

Type 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 


Sequence  of  Input  Data 


Mission  title 
Simulation  parameters 
Printout  recording  options 
Task  analysis  allocation 
Operator  characteristics 
Message  types 
Hour  parameters 
Mesage  originator 
Error  significance  probability 
Error  rate 

Message  length  - ratio  operator,  mean 

Message  length  - radio  operator,  standard  deviation 

Message  length  - controller,  mean 

Message  length  - controller,  standard  deviation 

Task  elements 

Task  analytic  data 

Effectiveness  computational  data 

Transmission  delay  data 


Table  2 

Input — Mission  Identification  and  Simulation  Parameters 

Card 

Mission  Title  (card  type  1)  Columns 


IDENT  A simulation  identifier  up  to  72  characters  long  is 

printed  at  the  top  of  each  page  of  printout. 

Simulation  Parameters  (card  type  2) 


1-72 


0R0(5) 

0R0(6) 

0R0(7) 

0R0(8) 


0R0(9) 


Recording  option  #5  - If  set  equal  to  1 detailed  task 
performance  data  are  recorded 
Recording  option  #6  - not  used 

Recording  option  #7  - If  set  equal  to  1 the  input 
data  may  be  changed  in  real  time  mode 
Recording  option  #8  - If  set  equal  to  3,  summary 
tables  upon  which  means  are  based  are  printed  before 
the  run  summary.  Also  the  message  characteristics  are 
printed  when  0R0(5)  equals  1. 

Recording  option  #9  ' not  used 


Format 


12A6 


NSHIFT 

The  number  of  repetitions 

of  the  simulation  to  be 

performed. 

1-3 

13 

IHMAX 

The  maximum  number  of  hours  per  iteration 

4-6 

13 

MAXIT 

The  maximum  number  of  message  types 

7-9 

13 

JMAX 

The  maximum  levels  within 

the  network 

10-12 

13 

MAXNET 

The  number  of  networks 

13-15 

13 

RY 

The  initial  value  for  the 

random  number 

generator . 

It  must  be  odd. 

16-24 

F9.0 

I DAY 

The  number  of  days  worked 

without  a day 

off 

25-27 

13 

NETREF(l) 

The  number  of  referees  in 

network  #1 

28-30 

13 

NETREF(2) 

The  number  of  referees  in 

network  #2 

31-33 

13 

NETREFO) 

The  number  of  referees  in 

network  #3 

34-36 

13 

Printout 

Recording  Options  (card  type 

3) 

ORO(l) 

Recording  option  #1  - not 

used 

1 

A1 

0R0(2) 

Recording  option  #2  - not 

used 

2 

A1 

0R0(3) 

Recording  option  #3  - Detailed  data  for  debug 

3 

A1 

0R0(4) 

Recording  option  #4  - not 

used 

4 

A1 

A1 

A1 

A1 


A1 

A1 
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Table  3 

Maximum  Value  for  Variables 

Upper 

Variable  Function  Limit 


IHMAX 

JMAX 

MAXI 

MAXIT 

MAXK 

MAXNET 

MAXSEG 


Maximum  number  of  hours 
Number  of  network  levels 

Maximum  number  of  task  elements  in  each  task  analysis 
Maximum  number  of  message  types 
Maximum  number  of  task  analyses 
Maximum  number  of  networks 

Maximum  number  of  time  segments  on  which  counts  can 
be  maintained 


NETREF(NET)  Number  of  referee/radio  operator  teams  per  controller 


12 

4 

10 

7 

8 
3 

20 

9 


The  number  of  levels  within  the  network  is  identified  by  the 
variable  JMAX.  The  value  of  JMAX  must  be  4 where  level  1 is  the 
referee  level,  level  2 is  the  radio  operator  level,  level  3 is  the 
computer  level,  and  level  4 is  the  controller  level. 

The  number  of  networks,  MAXNET,  controls  the  number  of  referee/ 
radio  operator/controller  strings  which  are  processing  messages 
simultaneously  through  a common  computer.  Up  to  three  networks  may 
be  simulated. 

The  stochastic  processes  used  within  the  model  are  controlled 
by  a pseudo-random  number  generator.  This  random  number 
generator  must  be  initialized  with  an  odd  number  from  which  it  pro- 
duces its  own  values  for  subsequent  random  numbers. 

Human  operator  fatigue  is  simulated  within  the  model  as  a 
function  of  hour  and  as  a function  of  the  number  of  days  worked 
without  a day  off.  The  variable  IDAY  identifies  the  number  of 
continuous  days  which  have  been  worked. 

The  number  of  referee/radio  operator  teams  per  controller  may 
be  varied  from  1 to  a maximum  of  9.  Different  numbers  of  referee/ 
radio  operator  teams  may  be  specified  for  each  controller  as  long 
as  each  individual  controller  has  no  more  than  nine  teams  in  his 
network . 
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The  output  recording  options  control  the  level  of  detail  of 
the  tabulations.  At  present,  only  options  5 and  7 are  used. 

Option  5,  provides  a maximum  level  of  detail  with  full  recording 
of  task  element  processing  including  performance  time,  success  or 
failure,  and  the  operator  factors:  stress,  fatigue,  level  of 
aspiration  which  are  active  during  the  performance  of  that  task 
element . 

Option  7 turns  program  control  over  to  a time  sharing  terminal 
after  the  basic  card  input  data  are  entered. 


Card  Type  4 

Table  4 presents  the  input  format  for  task  analysis  alloca- 
tion. Task  analyses  are  assigned  according  to  network  level  and 
message  type.  The  same  or  different  task  procedures  may  be 
assigned  to  each  network  level-message  type  combination  up  to  the 
maximum  of  eight  task  procedures. 
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Table  4 
(Card  Type  4) 

Input  - Task  Analysis  Allocation 


IATA(1,1)  - Task  procedure  used  by  network  level  1 for  processing 


IATA(1,2) 

_ 

message 

Network 

type  1 
level 

1 

message 

type 

2 

1-2 

3-4 

12 

12 

IATA(1,3) 

- 

Network 

level 

1 

message 

type 

3 

5-6 

12 

IATA(1,4) 

- 

Network 

level 

1 

message 

type 

4 

7-8 

12 

IATA(1,5) 

- 

Network 

level 

1 

message 

type 

5 

9-10 

12 

IATA(1,6) 

- 

Network 

level 

1 

message 

type 

6 

11-12 

12 

IATA(1,7) 

- 

Network 

level 

1 

message 

type 

7 

13-14 

12 

IATA(1,8) 

- 

Network 

level 

1 

message 

type 

8 

15-16 

12 

IATA(2,1) 

- 

Network 

level 

2 

message 

type 

1 

17-18 

12 

IATA(2,2) 

- 

Network 

level 

2 

message 

type 

2 

19-20 

12 

IATA(2,3) 

- 

Network 

level 

2 

message 

type 

3 

21-22 

12 

IATA(2,4) 

- 

Network 

level 

2 

message 

type 

4 

23-24 

12 

IATA(2,5) 

- 

Network 

level 

2 

message 

type 

5 

25-26 

12 

IATA(2,6) 

- 

Network 

level 

2 

message 

type 

6 

27-28 

12 

IATA(2,7) 

- 

Network 

level 

2 

message 

type 

7 

29-30 

12 

IATA(2,8) 

- 

Network 

level 

2 

message 

type 

8 

31-32 

12 

IATA(3,1) 

- 

Network 

level 

3 

message 

type 

1 

33-34 

12 

IATA(3,2) 

- 

Network 

level 

3 

message 

type 

2 

35-36 

12 

IATA(3,3) 

- 

Network 

level 

3 

message 

type 

3 

37-38 

12 

IATA(3,4) 

- 

Network 

level 

3 

message 

type 

4 

39-40 

12 

IATA(3,5) 

- 

Network 

level 

3 

message 

type 

5 

41-42 

12 

IATA(3,6) 

- 

Network 

level 

3 

message 

type 

6 

43-44 

12 

IATA(3,7) 

- 

Network 

level 

3 

message 

type 

7 

45-46 

12 

IATA(3,8) 

- 

Network 

level 

3 

message 

type 

8 

47-48 

12 

IATA(4,1) 

- 

Network 

level 

4 

message 

type 

1 

49-50 

12 

IATA(4,2) 

- 

Network 

level 

4 

message 

type 

2 

50-52 

12 

IATA(4,3) 

- 

Network 

level 

4 

message 

type 

3 

53-54 

12 

IATA(4,4) 

- 

Network 

level 

4 

message 

type 

4 

55-56 

12 

IATA(4,5) 

- 

Network 

level 

4 

message 

type 

5 

57-58 

12 

IATA(4,6) 

- 

Network 

level 

4 

message 

type 

6 

59-60 

12 

IATA(4,7) 

- 

Network 

level 

4 

message 

type 

7 

61-62 

12 

IATA(4,8) 

- 

Network 

level 

4 

message 

type 

8 

63-64 

12 

Card  Type  5 

Table  5 shows  the  input  format  for  the  operator  characteristics. 
Four  cards  of  card  type  5 are  read  in:  (one  for  each  network  level) 
referee  (J=  1),  radio  operator  (J=  2),  computer  (J=3),  and  controller 
(J=  4).  The  characteristics  are  speed,  precision,  stress  threshold 
and  level  of  aspiration. 
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Col umn 


Forma t 


Card  Ti/pe 

_5 

Col umn 

Forma t 

J 

Network  level.  Note:  a card  is  required  for 
level  3 (the  computer)  despite  the  fact  that 
these  factors  are  not  used 

1-2 

12 

F(J) 

Operator  speed 

3-12 

F10.2 

PREC(J) 

Operator  precision 

13-22 

F10.2 

STRM(J) 

Operator  stress  threshold 

23-32 

F10.2 

ASP(J) 

Operator  level  of  aspiration 

33-42 

F10.2 

Operator  speed,  F(J),  is  scaled  from  .9  to  1.1.  An  operator 
assigned  a .9  speed  is  approximately  10  percent  faster  than  a 1.0 
or  average  oper^:.tor,  and  a 1.1  operator  is  about  10  percent  slower 
than  an  average  operator. 

Operator  precision,  PREC(,J ) , is  scaled  similarly  to  speed.  An 
operator  with  a precision  of  .9  would  be  expected  to  commit  fewer 
errors  than  an  average  (1.0)  operator.  Similarly,  an  operator  with 
a precision  of  1.1  would  be  expected  to  commit  more  errors  than  an 
average  operator. 

Operator  stress  is  a facilitating  force  produced  by  working 
almost  continuously  with  no  breaks.  As  a stress  increases,  per- 
formance will  improve  up  to  some  maximum.  When  stress  reaches  the 
stress  threshold,  the  facilitary  effect  disappears  to  simulate  the 
case  in  which  operator  is  working  as  fast  as  he  can.  Stress  threshold 
from  2.1  to  2.7  may  be  selected.  A stress  threshold  of  2.3  has  been 
found  to  be  generally  satisfactory. 

Level  of  aspiration  represents  the  degree  of  success  or  error 
free  performance  which  a person  generally  tries  to  maintain.  Levels 
of  aspiration  of  from  .90  to  .99  have  been  found  to  be  appropriate 
where  1.0  represents  striving  for  absolute  perfection.  Level  of 
aspiration  is  modified  during  a simulation  depending  on  the  actual 
success/fail  ratio  and  level  of  stress. 

Card  type  5 data  is  read  in  by  subroutine  PEOPLE. 
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Card  Type  6 


Subroutine  INTYPE  reads  in  message  type  data  on  card  type  6.  One 
card  type  6 is  read  in  for  each  message  type  as  specified  by  MAXIT. 

A six  character  name,  NMTYP(IT),  is  entered  and  this  is  followed  by 
the  mean  number  of  messages  generated  by  a stimulus  message,  RMPS(IT). 
It  is  assumed  that  each  incoming  message  to  the  referee  will  generate 
at  least  one  and,  sometimes  more  than  one  message.  The  actual  number 
of  messages  generated  is  determined  stochastically  for  each  incoming 
message . 


Table  6 


Input  - Message  Types 


Card  Type 

6 

Card 

Columns 

Forma t 

IT 

Message  type 

1-2 

12 

NMTYP(IT) 

Name  of  message  type 

3-8 

A6 

RMPS (IT) 

Mean  number  of  messages  generated  by  the 
referee  for  each  stimulus  message 

9-18 

F10.2 

Card  T5 


The  hour  parameters  (card  type  7)  are  read  in  subroutine  HOUR. 

The  number  of  type  7 cards  read  is  determined  by  IHMAX. 

IGP(IH)  is  the  mean  number  of  messages  (from  whatever  source) 
received  by  each  referee  (see  Table  7).  This  number  is  used  in  con- 
junction with  IGR  (the  standard  deviation  of  IGP)  to  stochastically* 
determine  the  actual  number  of  messages  received  by  the  referee. 

Note  that  after  this  number  is  determined,  RMPS  is  used  to  determine 
how  many  messages  actually  enter  the  system. 

After  messages  are  generated,  the  variable  FRET  is  used  to 
determine  the  message  type.  FRET  is  the  proportion  of  all  messages 
which  are  of  the  particular  type.  For  example  in  hour  IH  the  values  in 
FRET(1,IH)  to  FRET(7,IH)  might  be  .1,  .2,  .3,  .4,  .5,  .6,  1.0.  Notice 
that  the  proportions  must  be  cumulative.  The  actual  proportion  fre- 
quency of  type  2 would  be  . 1 or  10  per  cent.  The  highest  numbered 
messages  type  used  must  always  have  a value  of  1.0. 

*Note:  In  all  calls  for  random  number  from  a normal  distribution  extreme  values 
greater  than  2.S  sigma  are  not  allowed.  In  the  case  of  a uniform  distribution, 
the  allowed  range  is  from  .001  to  .999. 
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Table  7 

Input  - Hour  Parameters 

Card  Type  7 

Card 

Column 

Forma t 

IH 

Hour  number 

1-2 

12 

IGP(IH) 

Mean  number  of  messages  incoming  to  each 
referee 

3-4 

12 

IGR(IH) 

Standard  deviation  of  IGP(H) 

5-6 

12 

lUR(IH) 

Not  used 

7-8 

12 

FRET(1,IH) 

Cumulative  proportional  frequency  - 
Message  type  1 

10-14 

1X,F5. 5 

FRET(2,IH) 

Message  type  2 

15-19 

F5.  5 

FRET(3,IH) 

Message  type  3 

20-24 

F5.  5 

FRET(4,IH) 

Message  type  4 

25-29 

F5.  5 

FRET(5,IH) 

Message  type  5 

30-34 

F5. 5 

FRET(6,IH) 

Message  type  6 

35-39 

F5.  5 

FRET(7,IH) 

Message  type  7 

40-44 

F5.  5 

FREP(1,IH) 

Cumulative  proportional  frequency  - 
Message  priority  1 

59-54 

5X,F5. 5 

FREP(2,IH) 

Message  priority  2 

55-59 

F5.  5 

FREP(3,IH) 

Message  priority  3 

60-64 

F5.  5 

FREP(4,IH) 

Message  priority  4 

65-69 

F5. 5 

FREP(5,IH) 

Message  priority  5 

70-74 

F5.  5 

Card  Type  8 

Table  8 shows  the  input  format  for  the  card  type  8 message 
originator  data.  Three  sources  of  message  organization  are  considered; 
controller,  another  referee,  and  current  referee.  The  probabilities 
across  message  originators  are  also  cumulative.  For  example,  the  values 
in  0RIG(1,1),  0RIG(2,1),  and  0RIG(3,1)  might  be  .1,  .4,  and  1.0. 

This  would  mean  that  the  controller  originates  10  per  cent  of  the 
messages  in  hour  1,  colateral  referees  generate  30  per  cent,  and  the 
referee  generates  them  himself  from  his  own  sources  60  per  cent  of 
the  time.  Naturally,  if  less  than  12  hours  are  being  simulated,  data 
for  hours  not  used  may  be  left  blank.  Three  type  8 cards  must  be 
read  in  and  the  order  must  be  controller  data  ( I0R=  1),  other  referee 
data  ( IOR=  2),  and  present  referee  ( I0R=  3). 
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Table  8 

Input  - Message  Originator 

Card 


Card  Type  8 (3 

cards 

TOR=  1 

to  3) 

Columns 

Forma t 

ORIGdOR.l) 

The  cumulative  probability  that 
originator  lOR  (1=  controller, 
2=  another  referee,  3=  present 
originated  the  current  message 

message 

referee ) 
in  hour  1 

1-4 

F5.3 

0RIG(I0R,2) 

Same 

in 

hour 

2 

6-10 

F5.3 

0RIG(I0R,3) 

Same 

in 

hour 

3 

11-15 

F5.3 

0RIG(I0R,4) 

Same 

in 

hour 

4 

16-20 

F5.  3 

0RIG(I0R,5) 

Same 

in 

hour 

5 

21-25 

F5.3 

0RIG(I0R,6) 

Same 

in 

hour 

6 

26-30 

F5.3 

0RIG(I0R,7) 

Same 

in 

hour 

7 

31-35 

F5.3 

0RIG(I0R,8) 

Same 

in 

hour 

8 

36-40 

F5.3 

0RIG(I0R,9) 

Same 

in 

hour 

9 

41-45 

F5.3 

0RIG(I0R,10) 

Same 

in 

hour 

10 

46-50 

F5.3 

0RIG(I0R,11) 

Same 

in 

hour 

11 

51-55 

F5.3 

0RIG(I0R,12) 

Same 

in 

hour 

12 

56-60 

F5.3 

I Card  Types  9 and  10 

i Various  sources  and  aspects  of  error  generation  are  considered. 

[ These  error  aspects  are  entered  in  subroutine  ERROR  and  read  in  on 

I card  types  9 and  10  as  shown  in  Table  9. 

I- 

I 

f Two  variables  read  in  concerning  error  are  PUL  and  PUS.  PUL 

I and  PUS  are  the  probabilities  of  errors  being  undetected  (and  there- 

fore uncorrected)  and  entering  the  computer.  PUL  is  the  probability 
of  an  insignificant  error  while  PUS  is  the  probability  of  a 
! significant  error.  PUL  and  PUS  are  used  in  the  computation  of 

f information  loss,  INFOLS, and  in  the  computation  of  the  accuracy  overall 

effectiveness  component. 

. Errors  are  divided  into  four  categories  as  shown  in  Table  9. 

One  card  type  10  must  be  entered  for  each  of  the  four  error  types 
although  the  order  of  error  types  is  not  important  since  the  appro- 
priate type,  IE,  is  identified  on  the  card  itself. 

Different  error  rates,  ER(IE,  IT),  may  be  identified  for  each 
error  type/message  type  combination.  These  are  error  rates  per 
100  characters  in  the  message.  Error  occurrence  in  the  model  is  a 
function  of  not  only  the  average  error  rate,  ER,  but  also  the 
precision,  PREC(J),  of  the  network  level  performing  the  work. 


Finally,  the  probability  that  a given  error  was  caused  by 
the  referee  is  indicated  by  ERPG(IE)  and  the  probability  that  an 
1*0  nno  T*n  1-r»r  ici  hv  FRP  T T K . 


Card 

Columns 


The  probability  of  entering  a non  important 
undetected  error  into  computer  for  each  message 
The  probability  of  entering  a significant  un- 
detected error  into  the  computer  for  each  message 


Type  of  error,  1=  commission,  2=  abbreviation, 

typographical  or  spacing,  3=  omission,  4=  other 

Error  rate  per  100  characters  of  message  type  1 

Same  for  message  type  2 

Same  for  message  type  3 

Same  for  message  type  4 

Same  for  message  type  5 

Same  for  message  type  6 

Same  for  message  type  7 

Probability  of  an  error  due  to  referee  error 
Probability  of  an  error  due  to  radio  operator  error 


ER(IE,1) 

ER(IE,2) 

ER(IE,3) 

ER(IE,4) 

ER(IE,5) 

ER(IE,6) 

ER(IE,7) 

ERPG(IE) 

FRPI(IE) 


The  message  that  the  referee  prepares  and  the  radio  operator 
transmits  is  different  than  the  message  received  by  the  controller. 
The  highly  coded  message  prepared  by  the  referee  ranges  from  12  to  22 
characters  in  length  while  the  message  received  by  the  controller 
is  longer  and  has  been  largely  decoded  into  prose. 


Card  Types  11,  12,  13,  and  14 


Table  10  shows  the  card  type  11,  12,  13,  and  14  formats  required 
for  entering  the  message  length  data.  These  data  are  entered  in 
subroutine  INCHAR. 


The  length  of  the  message  prepared  by  the  referee  is  determined 
stochastically  from  a normal  distribution  with  a mean  of  INC(IT) 
and  a standard  deviation  of  INS(IT).  Since  the  message  length  is 
identified  by  message  type,  different  message  types  can  have  different 
mean  lengths. 


The  length  of  the  message  received  by  the  controller  is  also 
generated  stochastically  from  a normal  distribution  with  a mean  of 
CHRCON(IT)  and  a standard  deviation  of  CHSCON(IT).  The  message 
length  is  one  factor  in  the  determination  of  the  time  to  process  a 
message . 


Table  10 


Card 

Columns 


Mean  message  length  (#  of  characters)  of 

message  type  1 to  radio  operator 

Same  for  message  type  2 

Same  for  message  type  3 

Same  for  message  type  4 

Same  for  message  type  5 

Same  for  message  type  6 

Same  for  message  type  7 


as  REAL 


Note 

Message  length  - radio  operator  standard  deviation.  Card  tuve  12 


Standard  deviation  of  INC(l) 
Standard  deviation  of  INC(2) 
Standard  deviation  of  INC(3) 
Standard  deviation  of  INC(4) 
Standard  deviation  of  INC{5) 
Standard  deviation  of  INC(6) 
Standard  deviation  of  INC(7) 


Note:  INS  is  explicitely  specified  as  REAL 

Message  length-  Controller , mean.  Card  typ' 


CHRCON(l)  Mean  message  length  of  characters)  of 
message  type  1 to  the  controller 
CHRC0N(2)  Same  for  message  type  2 
CHRC0N(3)  Same  for  message  type  3 
CHRC0N(4)  Same  for  message  type  4 
CHRC0N(5)  Same  for  message  type  5 
CHRC0N(6)  Same  for  message  type  6 
CHRC0N(7)  Same  for  message  type  7 


CHSCON(l)  Standard  deviation  of  CHRCON(l) 
CHSC0N(2)  Standard  deviation  of  CHRC0N(2) 
CHSCONO)  Standard  deviation  of  CHRC0N(3) 
CHSC0N(4)  Standard  deviation  of  CHRC0N(4) 
CHSC0N(5)  Standard  deviation  of  CHRC0N(5) 
CHSC0N(6)  Standard  deviation  of  CHRC0N(6) 
CHSC0N(7)  Standard  deviation  of  CHRC0N(7) 
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Exact,  step  by  step,  descriptions  of  the  procedures  used  to 
process  a message  must  be  entered.  Each  procedure  is  termed  a 
task  analysis,  K,  and  is  composed  of  task  elements,  I.  As  shown 
in  Table  3,  a maximum  of  eight  task  analyses,  MAXK,  can  be  entered 
and  a single  task  analysis  can  contain  no  more  than  10  task  elements 
MAXI . 


Card  Types  15  and  16 

The  task  analytic  inf ormation is  entered  into  subroutine  TASK 
through  card  type  15  whose  format  is  described  in  Table  11. 

The  first  parameter  to  be  entered  is  the  total  number  of 
task  elements  across  all  task  analyses,  NTE.  The  value  of  NTE 
determines  the  number  of  card  type  16 's  to  be  read  in. 

Each  card  type  16  identifies  the  task  analysis,  K,  and  task 
element,  I,  to  which  it  refers.  Accordingly,  these  cards  need  not 
be  in  serial  order  or  even  grouped  by  task.  It  is  recommended 
however,  that  they  be  sequenced  in  order  to  reduce  the  probability 
of  a set  up  error. 

The  variable  JTYPE(I,K)  identifies  special  types  of  task 
elements  which  must  be  processed  differently  from  regular  task 
elements.  Types  2 and  5 identify  task  elements  in  which  message 
length  must  be  taken  into  consideration  while  types  3 and  4 
merely  bypass  some  of  the  normal  task  element  processing.  Special 
types  of  task  elements  can  be  added  to  the  program  if  further 
effects  are  desired. 

Task  criticality  determines  whether  or  not  simulated  operator 
failure  or  success  on  the  task  will  be  considered  in  the  computa- 
tion of  the  operators  performance  level,  PERF(M).  The  perfoi'm- 
ance  level  is  compared  with  the  level  of  aspiration,  ASP(M),  to 
determine  if  an  aspiration  increment,  PAEA,  is  warranted. 

Message  processing  within  the  model  is  documented  in  terms 
of  message  segments.  Message  segments  are  defined  by  the  user.  How- 
ever, a segment  generally  indicates  critical  points  within  the  mess- 
age handling  process.  Up  to  20  segments,  MAXSEG,  may  be  accounted 
for  where  segment  1 is  the  time  at  which  processing  on  the  message 

by  the  referee  begins.  Other  segment  end  points,  2,3 20, 

are  indicated  in  END(I,J). 
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I 


Task  analysis  data  - Card  type  16 


(NTE  cards  read  in) 


K Task  analysis  number 

I Task  element  number 

JTYPEdjK)  Task  element  type.  Type  2 is  an  element  for  which 

the  number  of  referee/radio  operator  message  characters 
will  be  multipled  by  the  stochastically  determined  time 
to  produce  the  time  required  to  process  the  message. 
Type  3 is  a decision  element  where  operator  factors  of 
speed,  precision,  stress  are  not  allowed  to  affect  the 
duration  or  success  of  the  element.  Type  4 is  an  equip- 
ment element  where  operator  factors  are  not  considered 
and  the  task  cannot  be  failed.  Type  5 us  the  same  as 
Type  2 except  that  controller  message  length  is  used. 
Type  6 is  an  element  for  which  transmission  to  the 
computer  is  required. 

CRIT(I,K)  Criticality  of  the  task  element.  A "C"  identifies 
a critical  task 

END(I,K)  Message  processing  segment  ended  by  this  element 
if  any. 

IJF(I,K)  The  number  (i.e.  I)  of  the  task  element  which  will 
be  performed  subsequent  to  the  current  task  if  the 
current  task  is  failed. 

IJS(I,K)  The  number  of  the  task  element  which  will  be  per- 
formed subsequent  to  the  current  task  if  the  current 
task  is  performed  successfully.  If  left  blank  it 
signifies  the  completion  of  the  task  analysis. 
AVGTM(I,K)  The  average  performance  time 
SIGMA(I,K)  Standard  deviation  of  AVGTM(I,K) 

AVPROB(I,K)  Task  element  success  probability 

UETYPE(I,K)  Undetected  error  type.  T=  transform 

UEP(I,K)  Undetected  error  probability  (for  non  transform) 


1-2  12 
3-5  13 

7 IX, II 


8 A1 

9-10  12 
11-13  13 


14-16  13 


17-26  F10.2 

27-36  F10.2 

37-46  F10.2 

"7  A1 
48-53  F6.2 


The  sequence  in  which  task  elements  are  performed  is  controlled 
by  IJF(I,K)  and  IJS(I,K).  If  the  task  element  I is  failed  than  the 
element  specified  by  IJF(I,K)  will  be  performed  next,  while  if  the 
element  is  successful  then  IJS(I,K)  will  be  performed  next.  The 
probability  that  the  element  will  be  successful  is  indicated  by 
AVPROB(I,K)  while  the  probability  that  the  task  will  be  failed  is 
1 minus  AVPROB(I,K) 

The  average  time  to  perform  the  task  element  is  indicated  by 
AVGTM(I,K)  while  the  standard  deviation  is  SIGMA(I,K).  A number 
from  a normal  distribution  is  used  to  stochastically  determine  the 
particular  duration  at  a given  occurrence. 

A particular  error  type  accounted  for,  UETYPE(I,K)  is  the  trans- 
form error.  In  this  case,  the  number  of  characters  in  the  message 
being  prepared  by  the  referee  is  used  to  stochastically  produce 
errors  in  the  message.  The  probability  of  these  errors  is  indicated 
in  UEP(I ,K). 

The  overall  mission  effectiveness  is  computed  as  a weighted 
combination  of  four  types  of  effectiveness:  thoroughness,  completeness, 
responsiveness  and  accuracy.  Due  to  the  fact  that  these  factors  are 
not  independent,  a number  of  relationship  factors  must  be  used  in  the 
computation  of  mission  (overall)  effectiveness. 


Card  Type  17 

Table  12  shows  the  required  card  type  1,7  entries  for  computing 
mission  effectiveness.  All  of  these  values^  are  entered  in  the 
subroutine  EFFCOM. 

Correlations  between  each  of  the  effectiveness  components,  CC12 
through  CC34  are  entered  first.  The  entries  are  followed  by  the  rela- 
tive weight  or  importance,  W(NEC),  of  each  component . In  the  absence 
of  other  information,  correlations  of  .50  between  components  and 
equal  weights  of  .25  for  each  component  have  been  found  to  be  applic- 
able. However,  situations  in  which  a particular  factor  is  paramount 
would  warrant  assigning  a higher  weight  to  that  factor.  The  weights 
must  sum  to  1.0. 

When  the  radio  operator  attempts  to  send  a message  to  the 
computer,  he  must  first  find  an  open  frequency.  This  point  in  the 
radio  operator's  task  analysis  is  identified  by  a type  6 task 
element.  When  this  type  task  element  is  involved,  the  transmission 
delay,  DEL(IH),  is  used  with  the  standard  deviation,  DELSD(IH),  and 
a random  number  from  a normal  distribution.  This  time  is  added  to  the 
task  element  processing  time.  The  format  for  entering  the  required 
transmission  delay  data  is  shown  in  Table  13  (card  type  18). 


Ik. 
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Table  12 

Input  - Effectiveness  Computational  Data 

Effectiveness  components  (Card  type  17) 

Card 

Columns 

Forma t 

CC12 

Correlation  between  thoroughness  and  completeness 

1-4 

F4.4 

CC13 

Correlation  between  thoroughness  and  responsiveness 

.5-9 

F5.5 

CC14 

Correlation  between  thoroughness  and  accuracy 

10-14 

F5.5 

CC23 

Correlation  between  completeness  and  responsiveness 

15-19 

F5.5 

CC24 

Correlation  between  completeness  and  accuracy 

20-24 

F5.5 

CC34 

Correlation  between  responsiveness  and  accuracy 

25-29 

F5.5 

W(l) 

Relative  weight  of  thoroughness  in  computing 

30-34 

F5.5 

W(2) 

overall  effectiveness 

Weight  of  completeness 

35-39 

F5.5 

W(3) 

Weight  of  responsiveness 

40-44 

F5.5 

W(4) 

Weight  of  acucracy 

45-49 

F5.5 

The  weights  must  sum  to  1.0. 


Table  13 

Input  - Transmission  Delay  Data 


Transmission  (Card  type  18  IHMAX  cards) 


Card 

Columns  Format 


DEL(IH)  Mean  delay  required  for  radio  operator 
to  locate  an  open  frequency 
DELSD(IH)  Standard  deviation  of  DEL(IH) 


1-10  F10.2 

11-20  F10.2 
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Operations  and  Output 

The  program  may  be  controlled  through  either  a batch  processing 
or  a time  sharing  (real  time)  mode.  The  experimenter  control  or 
time  sharing  option  must  be  indicated  in  the  card  input  data. 

The  card  input  data  are  stored  in  the  data  file  MANM0D*NETCARD1 . 
A new  set  of  card  data  is  entered  in  the  following  card  sequence: 

(ffiRUN (standard  run) 

©ASG,  A MANMOD+NETCARDl. 

@DATA,IL  MANM0D*NETCARD1 


card  data  as  described  in  previous  section 


@END 

@FIN 

Inserting  a set  of  cards  in  this  fashion  automatically  erases  the 
previous  data  stored  in  NETCARDl. 

A simple  print  of  the  card  data  file  is  obtained  through  the 
card  sequence. 

@RUN. . . (standard  run  card) 

@ASG , A MANMOD+NETCARDl . 

©DATA , L 

©END 

©FIN 

The  NETMAN  program  is  called  up  on  the  U1108  facility  at  Edgewood 
Arsenal  byan  appropriate  RUN  identification  followed  by  the  instruc- 

©ASG.A  MANMOD*TRY. 

©ADD  TRY.NETMANl 


This  instruction  contains  the  following: 


©ASG , A 

NETMAN. 

©ASG,  A 

NETPRTl. 

©ASG,  A 

NETCARDl. 

©USE 

7 , NETCARD2 

©USE 

2,NETPRT2 

©XQT 

NETMAN. NETMAN 
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which  prepares  the  program  file  (NETMAN),  the  output  file  (NETPRTl), 
and  the  input  file  (NETCARDl)  and  then  executes  the  program. 


When  the  program  is  in  the  experimenter  control  mode,  a number 
of  messages  and  data  change  categories  will  be  presented  to  the 
time  sharing  terminals.  These  categories  are  self  explanatory. 

When  all  desired  simulations  have  been  completed,  the  program,  is 
terminated  by  selecting  a data  category  greater  than  22  to  be 
changed  (only  22  categories  are  available  to  be  changed)  and  then 
entering  @END  when  the  computer  indicates  it  is  ready  for  another 
instruction . 

The  output  record  from  the  simulation  may  be  printed  in  a number 
of  different  ways.  The  fastest  is  to  immediately  enter  the  follow- 
ing instructions  at  the  time  sharing  console: 

(no  RUN  instruction  is  necessary  unless  the 
previous  RUN  was  terminated) 


@ASG,CP  T 
@BRKPT  PRINT$/T 
@DATA,L  NETPRTl 
@END 

@BRKPT  PRINT$ 

©FREE  T 

@SYM  T,,ARI318 

©END 

The  results  should  begin  printing  on  the  printer  almost 
immediately.  "ARI318"  identifies  the  printer  in  the  ARI  facility. 

The  output  data  may  also  be  printed  via  cards  using  the 
following  cards; 

©RUN 

©ASG , A MANMOD . NETPRTl 
©DATA , L MANMOD . NETPRTl 
©END 
©FIN 

In  the  case  that  a printer  is  not  immediately  available, 
printouts  may  be  directed  to  the  Edgewood  Arsenal  for  mailing  to  the 
user.  The  instructions  to  be  used  in  this  case  are: 
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I*. 


@RUN (if  required)  r 

©SUSPEND  I 
©DATA , L MANM0D*NETPRT1  J 
©END  I 
©RESUME, P I 
©FIN  i 

I 

The  P option  following  the  instruction  RESUME  will  cause  an  I 
immediate  printout  (when  a printer  is  available)  at  the  U1108  | 
facility  at  the  Edgewood  Arsenal.  j 

I 

The  print  file  must  be  printed  or  copied  to  another  file  j 
before  the  simulator  program  is  called  up  again.  Otherwise,  the  * 
data  will  be  irreversibly  lost  as  new  data  are  entered  into  the  \ 
file.  The  data  may  be  copied  by  the  following  sequence  of  instruc-  1 
tions. 


©RUN (if  necessary) 

@ASG,CP  MANMOD*NEWFILE. ,F2///1000 
©ASG,A  MANM0D*NETPRT1 

©COPY  MANM0D*NETPRT1. ,MANMOD*NEWFILE . 

©END 


where  any  new  file  name  may  be  used  as  long  as  it  is  not  currently 
catalogued  under  the  MANMOD  project  ID. 


Interactive  Mode 

In  the  interactive  mode,  the  simulation  parameters  may  be 
changed  through  a direct  time  sharing  computer  link.  The  procedure 
required  to  call  the  program  is  described  in  the  section  on 
program  control  language.  Once  the  program  has  been  called  in  the 
interactive  mode,  the  display  shown  below  will  appear  at  the  remote 
console : 
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After  receiving  this  display,  the  new  line  (or  return  button  depending 
on  the  type  of  time  sharing  terminal)  button  should  be  depressed.  A 
new  display  will  appear; 

[ ] WHICH  DATA  CATEGORY  IS  TO  BE  CHANGED? 

ENTER  99  IF  YOU  WISH  TO  SEE  THE  TABLE  OF  CATEGORIES. 

The  data  category  to  be  changed  should  be  placed  in  the  location  in- 
dicated by  brackets.  This  number  must  be  right  justified  (i.e.,  no 
blanks  between  number  and  right  bracket).  An  entry  of  99  (followed 
by  depressing  the  new  line  button)  will  cause  a list  of  the  categories 
which  can  be  changed  to  appear.  After  viewing  the  list,  depressing  : 

the  new  line  button  will  return  the  program  to  the  display  shown  ' ] 

above.  The  new  line  button  must  be  pressed  after  each  entry  or  , 

point  at  which  the  computer  stops  and  is  waiting  for  a response.  Note 
that  numbers  entered  in  a CRT  type  terminal  should  be  entered  exactly  | 

within  the  brackets  whereas  an  entry  on  a paper  printer  type  of  i 

terminal  requires  that  the  entry  be  transposed  one  column  to  the  right 
of  the  indicated  location.  In  both  cases,  it  is  not  required  that 

t ;e  entry  be  made  on  the  line  on  which  the  brackets  appear.  The  new  , 

entry  may  be  made  on  any  line,  as  long  as  the  correct  columns  are 

used. 
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An  example  of  a simulation  change  would  be  to  enter  12  as  the 
data  category  to  be  changed.  The  old  simulation  identifier  will 
appear  as  shown  below: 

[SENSIT  RUN  9 16  MSG  WITH  17  CHAR  ] 

INSERT  NEW  MISSION  TITLE  ABOVE 

A new  title  should  be  entered  between  the  brackets. 

The  data  category  display  will  appear  again.  If  9 is  selected, 
the  following  display  will  appear: 

[ ]=HOUR  [ ]=NUMBER  OF  MESSAGES. 

INDICATE  CHANGES  ABOVE.  CHANGES  WILL  BE  REFLECTED  BELOW 

MEAN  NUMBER  OF  MESSAGES  ARRIVING  PER  HOUR 
HOUR  NUMBER  OF  MESSAGES 

1 10 

2 10 

3 0 

4 0 

5 0 

6 0 

7 0 

8 0 

9 0 

10  0 

11  0 

12  0 

By  filling  in  the  appropriate  column(s).  The  mean  number  of  messages 
arriving  each  hour  can  be  changed.  If  any  change  is  indicated,  the 
display  will  repeat  with  the  new  value  shown  replacing  the  old  value. 
When  all  desired  changes  have  been  entered,  depressing  the  new  line 
key  without  having  made  any  entry  will  return  the  program  to  the 
data  category  selection  display. 

As  a third  example,  if  data  category  4 is  selected  operator 
precision  may  be  changed. 

[ ]=  OPERATOR  NUMBER  [ 1=  PRECISION 

INDICATE  CHANGES  ABOVE.  CHANGES  WILL  BE  REFLECTED  BELOW. 
OPERATOR  PRECISION 

1 1.00 

2 1.00 

3 1.00 

4 1.00 
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If  any  precision  value  is  changed,  the  table  will  be  displayed 
and  indicate  the  new  value.  When  no  change  is  indicated  the  data 
category  selection  will  return.  The  following  variables  may  be 
selected  for  change: 

1.  number  of  iterations 

2.  output  options 

3.  operator  type  data 

4.  operator  precision 

5.  operator  aspiration 

6.  mean  time  for  tasks 

7.  message  error  rate 

8.  probability  of  an  error  of  low 
significance 

9.  incoming  messages  to  referee 

10.  message  priority  occurrence  rate 

11.  sigma  for  characters 

12.  mission  title 

13.  task  analysis  indicators 

14.  operator  speed 

15.  operator  threshold 

16.  sigma  for  task  time 

17.  probability  of  significant  error 

18.  sigma  referee  messages 

19.  message  type  occurrence  rate 

20.  mean  number  of  characters  per  referee 
message 

The  technique  for  change  in  all  cases  is  the  same  as  that 
described  above. 

Making  no  entry  in  the  data  selection  display  signals  the 
completion  of  data  changing  and  the  program  goes  automatically  into 
i simulation.  Any  changes  made  will  be  automatically  recorded  in  the 

[ print  file. 

After  the  simulation  is  completed,  the  program  will  return 
(after  showing  summary  data)  to  the  data  selection  display.  Enter- 
ing the  value  76  in  the  category  to  be  changed  will  provide  a 
normal  termination  of  the  program.  This  is  the  desired  way  to 
terminate  the  program  since  it  causes  the  program  to  write  an  end 
of  file  mark  in  the  print  file.  Without  this  end  of  file  mark, 
file  printing  problems  can  be  induced. 

In  the  process  of  adapting  the  NETMAN  model  for  interactive 
processing  extended  core  was  necessary.  This  system  option  was 
exercised  through  the  addition  of  the  statement  "COMPILER(XM=  2)" 
in  front  of  each  subroutine. 

i 
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NETMAN  MACRO  FLOW 


1.0  2.0  3.0 


4.0  6.0 


7.0 


3.0 


2.0 


10.0  i 


COMPUTE  OVE?- 

SUMMARY 
STATlSTi  ‘ 
RUNSl'M 
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1.0  INPUT  ROUTINES 


READ  SIMULATION 

READ  OPERATOR 

PARAMETERS  [SIMPAM] 

PARAMETERS  [PEOPLE] 

READ  HOUR 
PARAMETERS  [HOUR] 


READ  ERROR  DATA 
[ERROR] 


I 

READ  TASK  DATA 

IS  EXPERIMENTER 

[TASK] 

INTERACTION  INDICATED? 

1 

SWITCH  TO  EXPERIMENTER 
INTERACTIVE  MODE  [EXPER] 


I 


2.0  MESGEN 


2.2  2.3 


2.'; 
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3.0  REFRE 


SET  UP  INITIAL 
CONDITIONS 


REPEAT  STEPS 
3.3  - 3.7  FOR  EACH 
REFEREE 


SET  TO  CONSIDER  REFEREE'S 

NEXT  MESSAGE 

MSG 

= LMSGIIREF.NET) + 1 

CMSG 

= IQONE(MSG,IREF,NET) 

J 

> MSGCHRICMSG,  5) 

IT 

= MSGCHRICMSG,  3) 

K 

= lATAIJ.IT) 

COMPUTE  STRESS 
[STRESS] 


COMPUTED'  'RATION 
[ASPIRr 


COMPUTE  FATIGUE 
[FATIGUl 


PROCESS  MESSAGE  CMSG 
ACCORDING  TO  TASK 
ANALYSIS  K [PROC] 


3.7  (ALSO  4.7,  AND  7.7) 


OPTIONAL 
PRINT  START  OF 
MESSAGE  DATA 


ISJ=  1? 


ACCUMULATE  START 
OF  MESSAGE  DATA 
CTSTOT.I)  +Z(M) 
NCTST(IT,1)  + 1 
CTSH(IH,1)  + Z(M) 
NCTSHdH.I)  + 1 


IF  RY<  UEP(I,K)  • 1/PREC(J) 
ERRORS" ERRORS + 1 


CALCULATE  TASK  ELEMENT  TIME 
V - AVGTMd.K)  + RD  • SIGMA(I,K) 
TIME  - F(J)  • V • ZIP  • PAFA  • PAFW 
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3.7.12  3.7.13 
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4.0  RADOP 


r 


5.0 


Li 


03 


6.0  CCC 

M 

I 

; 6.1  6.2 


I 

I 
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7.0  CONTR 


* 
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L-i 


-A- 


A — Temporary  variable  used  when  arithmetic  calculations  are  made 
with  an  integer  variable. 

AHT — Average  handling  time  for  a message. 

AM--Mean  number  for  poisson  distribution. 

ASP(M) — Mean  final  aspiration  level  for  each  man.  An  aspiration 

of  1.0  represents  striving  for  perfection.  An  aspira- 
tion level  of  .9  has  been  found  appropriate  in  many 
situations. 

ASS(M) — Mean  final  aspiration  level. 

ATPM — Average  time  per  message  processing. 

AVGTM(I,K) — Average  task  element  performance  time. 

AVPR0B(I,K) — Task  element  success  probability.  That  is, the 

probability  that  the  following  task  will  be  US  and 
not  IJF. 


-B- 

B — Temporary  variable  used  when  calculations  must  be  made  using 
an  integer  variable. 


-C- 

CCC — Subroutine  used  to  select  each  message  for  computer 
processing. 

CC12 — The  average  correlation  between  the  effectiveness  of 
measures  thoroughness  and  completeness. 


CC13 — The  average  correlation  between  the  effectiveness 
measures  thoroughness  and  responsiveness. 


CC14--The  average  correlation  between  the  effectiveness  measures 
thoroughness  and  accuracy. 

CC23 — The  average  correlation  between  the  effectiveness  measures 
completeness  and  responsiveness. 

CC24 — The  average  correlation  between  the  effectiveness  measures 
completeness  and  accuracy. 

CC34 — The  average  correlation  between  the  effectiveness  measures 
responsiveness  and  accuracy. 

CEC(IH,IOP) — Accumulative  effectiveness  measures  for  run  summary. 

CFA( IH, J )--Cumulative  final  aspiration  level  for  run  summary. 

CFS(IH,J) — Cumulative  final  stress  level  for  run  summary. 

CH(IS) — Cumulative  segment  completion  times. 

CHAR(37) — The  array  in  which  characters  are  stores.  In  the  order, 
1,2, 3, 4, 5, 6, 7, 8, 9,0,  blank,  A , B ,C ,D ,E ,F , G ,H , I , J , K , L , 
M,N,0,P,Q,R,S,T,U,V,W,X,Y,Z. 

CIDH(IH,J) — Cumulative  time  idle  for  run  summary, 

CMSG — Cumulative  message  number.  A unique  number  (within 

iterations)  assigned  to  each  message  when  it  is 
created.  Explicitly  specified  as  integer. 

CMTG(IH,M) — Time  spent  on  message  processing  per  man  per  hour. 

COMBLK — Procedure  definition  processor  in  which  common  (Variables 
in  Dimensions)  is  stored, 

C0MMNS(5) — Overall  effectiveness  measures  for  run. 

CONMSG — Subroutine  in  which  the  number  of  characters  in  the 

message  received  by  the  controller  is  determined. 

CONTR--Subroutine  used  to  select  each  message  for  controller 
processing. 

CP(IP,IS) — Iteration  mean  performance  time  per  priority  per 
segment . 

CRIT(I,K) — Criticality  of  the  task  element,  C=  critical. 
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CHRCON(IT) — Mean  number  of  characters  displayed  to  the  controller 
for  each  message  type. 

CHSCON(IT) — Standard  deviation  ^f  CHRCON(IT). 

CT(1T,IS) — Iteration  total  time  per  segment  per  message  type. 

CTSH(IH,IS) — Cumulative  segment  time  by  hour. 

CTSP(IP,IS) — Cumulative  time  segments  by  message  priority  data 
for  run  summary. 

CTST(IT,IS) — Cumulative  time  segments  by  message  type  data  for 
run  summary. 

CTWH(IH,J) — Cumulative  performance  level  for  run  summary. 


-D- 


D--Dummy  indexer  used  for  glossary  reference  to  matrix. 

DEL(IH) — Mean  transmission  to  computer  delay. 

DELSD(IH) — Standard  deviation  of  transmission  to  computer  time. 

DIGIT( ID)--Subroutine  in  which  the  number  of  digits  in  the 
message  prepared  by  the  referee  is  determined. 

-E- 

EC(IH,IC) — The  value  of  each  effectiveness  component. 

EFF — Overall  or  composite  effectiveness. 

END(I,K) — Message  processing  segment,  if  any,  ended  by  this 
task  element. 

ER( IE , IT)--Error  rate  per  100  characters  for  each  type  of  error 
-IE-  and  each  type  of  message,  IT. 

ERP(IE) — Proportions  of  errors  which  will  cause  computer  error 
messages . 

ERPG--Proportion  of  Referee  errors  which  will  cause  computer 
error  messages. 

ERPI — Proportion  of  Radio  Operator  errors  which  will  cause  computer 
error  messages. 


s 

f 
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-E- 


ERSUMT( IT, lOP )--Error  sums. 

EXASP(M) — Aspiration  level  per  man  in  run  summary. 
EXASPH( IH,M)--Aspiration  level,  run  summary. 
EXTPMH(IH,M) — Time  per  message,  run  summary. 


-F- 

F(J) — The  speed  factor  of  each  man.  An  average  man  would  be  1.0. 

A fast  man  would  be  .8  and  a slow  man  would  be  1.2. 

FREP(IP,IH) — The  cumulative  proportional  occurrence  of  message 
priority  -IP-  as  IP  goes  from  1 to  5 during  hour 
IH.  The  highest  used  priority  within  each  hour 
must  have  a proportion  of  1.0. 

FREQ — Subroutine  used  to  input  transmission  delay  to  the  computer. 

FRET(IT,IH) — The  cumulative  proportional  occurrence  of  message 
IT  as  IT  goes  from  1 to  ITMAX  during  hour  IH.  For 
example  FRET  (1-7,  1)  might  be  .1,  .23,  .25,  .48, 

.73,  .84,  1.00.  Used  in  random  calculation  of 

actual  message  types  in  any  given  simulation  hour. 


-G- 


GMEANS — Grand  means. 

GTSMNS — Grand  total  means. 


-II- 

HROVER — Indicator  for  hour  completion. 


-I- 

I--Task  element  number.  Also  temporary  index. 

IATA(J,IT) — Task  analysis  to  be  used  for  each  operator  type,  J 
and  for  each  message  - IT. 
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ICF — Temporary  counter  for  number  of  messages. 

ICHAIN — Number  of  messages  to  be  processed  in  each  iteration. 

ID — The  number  of  digits  in  the  message  prepared  by  a referee. 
Argument  in  subroutine  DIGIT. 

IDAY — Day  of  mission  simulation.  Used  in  computation  of  fatigue. 

IDENT(18) — A run  description  or  header  of  72  characters  printed 
on  the  top  of  each  page  of  printout. 

IDONE — The  current  number  of  messages  completed  by  controller. 

IDL(IH,J) — The  amount  of  idle  time  for  each  man  in  each  hour. 

IDUM — Dummy  variable. 

IE — Error  type,  1=  commission,  2=  typographic  (includes  abbrevia- 
tion and  spacing),  3=  omission,  4=  other. 

lEND — Option  to  terminate  program  (when=  1). 

lEK — Time  segment  indicator  point. 

IFTET — Temporary  storage  for  IFTE. 

IGP(IH) — Number  of  messages  arriving  per  hour  IH. 

IGR(IH) — Standard  deviation  of  IGP(IH). 

IH — Hour  number. 

IHH — Index  for  hour, 

IHMAX — Temporary  indexer. 

IJF(I,K) — The  number  of  the  task  element  to  be  performed 
next  if  the  current  task  element  is  failed. 

IJS(I,K) — The  number  of  the  task  element  to  be  performed  next 
if  the  current  task  element  is  performed 
successfully . 

INC(IT) — Mean  number  of  characters  in  the  message  provided 
by  the  referee.  Explicitly  specified  as  REAL. 
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INFHR(IH) — Information  lost  per  hour. 

INFOLS(CMSG) — Information  loss  in  current  message. 

INS(IT) — Standard  deviation  of  number  of  characters  per 

message  type,  INC(IT).  Explicitly  specified  as 
REAL. 

INT(M) — Number  of  error  returns  remaining  in  hour  interrupted 
message  data. 

INTOP — Option  for  card  input  of  interruption  and  transmission 
delay . 

INTS — Total  number  of  interruptions  to  be  run  in  a task  element. 

lOP — Option  code. 

lOR — Indexer  for  message  originating  point,  1=  normal,  2= 
another  referee,  3=  controller. 

IP — Message  priority  number  where,  1=  routine,  2=  priority,  3= 
operational  immediate,  4=  flash,  5=  presidential 
interrupt.  Argument  in  subroutine  MPRIOR. 

IPAGE — Page  number  of  printout. 

IPD--Random  number  from  a poisson  distribution. 

IPRI (CMSG)--Message  priority. 

IPTl--Pointer  for  random  access  file  1. 

IPT2 — Pointer  for  random  access  file  2. 

IPT3--Pointer  for  random  access  file  3. 

IPT4--Pointer  for  random  access  file  4. 

IPT5 — Pointer  for  random  access  file  5. 

IPT6 — Pointer  for  random  access  file  6. 

IQONE(MSG, IREF,NET) — Queue  of  all  coming  messages. 


IREF — Indexer  for  referee  within  network. 

IRESH( lOP , IH) — Information  lost  ( IOP=  6)  number  of  error 

return  ( IOP=  5)  tasks  performed  per  hour  (IOP=  7), 
lOP  1 to  4 accumulate  errors  per  error  type. 

IREST( lOP, IT) — Information  lost  (IOP=  6),  number  or  error  return 
(IOP=  5),  tasks  performed  (IOP=  7)  per  message  type. 
lOP  1-4  accumulate  number  of  errors  per  error  type. 

IS — Time  segment  for  message  processing. 

ITEM — Temporary  storage. 

ITYMAX — Maximum  number  of  interruption  types  per  task  element. 

lUR(IH)— Not  used. 


-J- 

J — Operator  type,  1=  referee,  2=  radio  operator,  3=  computer, 

4=  controller. 

JE--Index  for  type  of  message  and  other  purposes. 

JJ — Temporary  index  for  operator  type. 

JTYPE(I,K) — Task  element  type  for  element  I of  task  analysis  K. 

Allowable  types  are,  2=  task  element  in  which  the 
number  of  characters  for  this  message  type  will  be 
multiplied  by  the  stochastically  determined  mean 
time  to  produce  the  time  required  to  transform  the 
messages,  3=  a decision  task  element  where  operator 
factors  such  as  speed  - F(M),  precision-  PREC(M),  and 
stress  level  - STR(M)  are  not  allowed  to  affect  the 
duration  or  success  probability  of  the  task  element, 
4=  an  equipment  task  element  where  operator  factors 
are  not  considered  and  the  task  can  not  be  failed, 

5=  not  used,  6=  a task  in  which  a transmission  to 
the  computer  occurs. 
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-K- 

K — Task  analysis  number. 

KK — Temporary  index  for  message  queue  and  others. 

-L- 

LDONE — Counter  for  messages  completed. 

LMSG(IREF,NET) — Last  message  processed  by  each  referee  in 
each  network. 

LTH — Number  of  characters  in  message  to  controller.  Argument 
in  COMSG. 

-M- 

M — Man  machine.  Each  man  involved  in  a simulation  is  assigned  a 
unique  number. 

MANT — Temporary  storage  for  MAN. 

MCL(M) — Messages  completed  per  man  for  run  summary. 

MCUM — Cumulative  message  number  of  current  message. 

MEN(D) — Number  of  men,  D=  1,  for  referees,  D=  2 for  radio  operators, 
D=  3 for  computer,  D=  4 for  controllers. 

MENS — Total  number  of  men  in  system. 

MESS(LA,J) — Messages  for  performance  this  hour,  LA=  1 total  for 
hour;  LA=  2 messages  remaining  for  hour.  This 
category  is  decreased  as  messages  are  performed. 

MGCP(IH,M) — Cumulative  messages  completed. 

MQCPL(IH,M) — Messages  completed  per  hour  per  man. 

MSCPL(M) — Messages  completed  per  man. 

MSEL — Man  initials  selected  to  perform  next  task. 

MSG — Message  position  within  queue. 

MPRIOR — Subroutine  in  which  message  priority  is  determined. 

MTYPE — Subroutine  in  which  message  type  is  determined. 
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MSGCHR(CMSG, IMC) — Message  characteristics  array.  IMC=  1 for 
message  length  in  digits  (RO),  2=  priority,  3= 
type,  4=  origin  (1  for  outside,  2 for  controller, 

3 for  other  referee),  5=  level  (J)  where  message 
currently  is,  7=  message  length  for  controller,  8= 
NET,  6~  man  number  (M),  9=  IREF  or  IRQ  depending 
on  J. 

MSGNO — Number  of  messages  being  processed. 

MSGS — Message  number  index. 

MSGT — Temporary  storage  for  CMSGNO. 

MUCOMP(IH,J) — Cumulative  messages  completed  per  hour,  queue  for 
run  summary . 


-N- 

NAME(M) — The  name  or  title  for  each  man  (up  to  6 characters). 

NCP(IP) — Number  of  tasks  performed  on  each  priority. 

NCT(IT) — Number  of  times  task  types  are  completed  in  current 
iterations , 

NCTSH(IH) — Number  of  messages  performed  per  hour  for  run  summary. 

NCTSP(IP) — Number  of  task  performance  by  priority  data  for  run 
summary . 

NCTST(IT) — Number  of  times  task  types  completed  across  all 
iterations . 

NERT — Temporary  storage  for  controller  network. 

NET — Indexer  for  controller  network. 

NETREF(NET) — Number  of  referees  in  each  controller  network. 

NOFAIL(M) — Number  of  task  element  failures  in  an  hour. 
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NOMSG — Cumulative  priority  weight  of  message  in  queue. 

NOSUC(M) — Number  of  task  element  successes  in  an  hour, 

NSHF — Current  iteration  number. 

NSHIFT — Total  number  of  iterations  to  be  performed, 

NTE — Number  of  task  elements,  total  across  all  task  analyses. 
Used  in  data  input. 

NTMT(IT) — Number  of  tasks  performed  by  type. 

NUET — Temporary  storage  for  TNUE. 

N1 — Temporary  index. 

N2 — Temporary  index. 

N3 — Temporary  index. 

N5--Temporary  index. 

-0- 

0RIG(I0R,IH) — Cumulative  probability  for  originating  a message. 

I0R=  1 normal,  2=  another  referee,  3=  controller. 

ORIGIN — Subroutine  in  which  the  originating  point  for  each 
message  is  determined. 

ORO(D) — Output  recording  option. 


-P- 

PAFA — Pace  adjustment  factor  for  aspiration  level. 

PAFW — Pace  adjustment  factor  for  work  fatigue. 

PASP(J) — Permanent  or  initial  aspiration  level  for  each  crewman. 

Used  for  resetting  the  aspiration  level  at  the 
beginning  of  each  iteration. 

PERF(M) — The  performance  level  of  M.  PERF(M)=  NOSUC(M)/(NUSUC(M)  + 
NOFAIL(M) . 
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PRIOR(MSG,J) — Message  priority. 

PRIORT — Temporary  storage  for  message  priority. 

PROS — Temporary,  adjusted,  task  element  success  probability. 

PROBI ( I ,K, ITYP) — Probability  of  occurrence  of  task  element 
interruption . 

PROBOP(NOP) — Probability  (cumulative)  that  each  Information  search 
option  will  be  selected  for  performance. 

PROP — Temporary  variable  used  for  numerous  proportions. 

PRP(IS) — Proportion  of  message  handling  time  spent  in  each 
segment . 

PUL — Probability  of  a low  importance  undetected  error  getting 
through  to  the  central  computer  data  store. 

PUS — Probability  of  a significant  error  undetected  error 
getting  through  to  the  computer  data  store. 


-R- 

RADOP — Subroutine  used  to  select  the  next  message  for  each 
radio  operator. 

RANDN(RY,RD,M, SD) — Subroutine  which  produces  a pseudo  random 
from  a normal  distribution  with  mean  M and  a 
standard  deviation  SD. 

RANDU(RY,D) — Subroutine  which  produces  a pseudo  random  number 
from  a uniform  distribution  between  0 and  1.  The 
second  argument  must  always  be  1. 

REFRE — Subroutine  used  to  select  the  next  message  for  each 
referee . 

RD — Pseudo  randum  number  from  a uniform  distribution.  Mean 
and  sigma  specified  by  input  data. 

RID — Temporary  storage  of  REAL  value  of  ID. 

RLTH — Temporary  REAL  version  of  LTH. 

RMPS(IT) — The  mean  number  of  messages  produced  for  each  referee 
received  item  by  message  type, 

RY — Pseudo  random  number  from  a uniform  distribution  between  0 
and  1. 
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SEGS(CMSG. ISEG) — Time  at  which  each  message  segment  is  completed. 

SF — Stress  factors. 

SHFTOV — Shift  completed  indicator. 

SIF — Success  or  fail  indicator,  S=  success,  F=  fail.  i 

i’ 

SIGMA(I,K) — Standard  deviation  of  the  mean  task  element  per-  * 

formance  time  - AVGTM(I,K).  j 

SRS(M) — Average  final  stress  per  man.  i 

SRTA — System  average  response  time  to  an  inquiry. 

SRTS — Standard  deviation  of  the  system  response  time  to  an 
inquiry. 

ST — Starting  time  for  message  processing. 

START(M) — Actual  starting  time  for  message  which  was  interrupted 
by  hour  and  processing. 

STR(M) — Current  crewman  stress  level. 

STRM(M) — The  stress  threshold  for  each  man. 


-T- 

TARIV(MSG,J) — Time  of  message  arrival  in  queue. 
TARVT — Temporary  storage  for  TARIV. 


TIE1(MSG,M)- 

-Total 

number 

of 

undetected 

errors 

of 

type 

1. 

TIE2(MSG,M)- 

-Total 
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of 
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of 

type 

2. 

TIE3(MSG,M)- 
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of 
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TIME — Task  element  performance  time. 

TLEN — Intermediate  value  in  the  computation  of  message  length. 
TMIDL — Average  idle  time. 

TMI(M) — Mean  idle  time. 

TMT(MSG,J) — Total  number  of  undetected  errors  in  a message. 
TPM — Time  per  message. 

TPCM(M) — Time  per  message  per  man. 

TRDEL — Transmission  delay  time. 

TW(IH,M) — Amount  of  time  (seconds)  worked  by  each  crewman 
during  each  hour 


-U- 

UEP(I,K) — The  probability  of  the  occurrence  of  an  undetected 
error. 

UETYPE(I,K) — Undetected  error  type,  T=  transfer. 

-V- 

V — Basic  execution  time  function. 


-W- 

W(IC) — The  relative  weight  of  each  effectiveness  component  in 
computing  overall  effectiveness. 

WOR(.M) — Mean  time  worked. 


-X- 

X — Temporary  storage  for  ICHAIN. 
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Y — Number  used  to  initialize  the  random  number  generator. 


-Z- 
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Z(M) — Current  time  (seconds)  for  each  crewman. 

ZA — Adjusted  task  element  success  probability  when  stress  level 
exceeds  the  stress  threshold. 

ZIF — Stress  function  for  execution  time. 

ZIH — IH  minus  1 in  seconds. 
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